From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Lan Tianyu" <tianyu.lan@intel.com>,
"Yang Zhang" <yang.zhang.wz@gmail.com>,
"Radim Krčmář" <rkrcmar@redhat.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org, tglx@linutronix.de,
gleb@redhat.com, mst@redhat.com, x86@kernel.org,
Peter Xu <peterx@redhat.com>, Igor Mammedov <imammedo@redhat.com>
Subject: Re: Enable more than 255 VCPU support without irq remapping function in the guest
Date: Wed, 27 Apr 2016 08:56:56 +0200 [thread overview]
Message-ID: <572062B8.5030103@siemens.com> (raw)
In-Reply-To: <57205B12.6070003@intel.com>
On 2016-04-27 08:24, Lan Tianyu wrote:
> On 2016年04月27日 13:24, Jan Kiszka wrote:
>>>> If we don't want the interrupt from internal device delivers to CPU
>>>>>> 255, do we still need the VT-d interrupt remapping emulation? I think
>>>> firmware is able to send IPI to wakeup APs even without IR and OS is
>>>> able to do it too. So basically, only KVM and Qemu's support is enough.
>
> Yes, just starting more than 255 APs doesn't need IR.
>
>> What are "internal devices" for you? And which OS do you know that would
>> handle such artificial setups without prio massive patching?
>>
>> We do need VT-d IR emulation in order to present our guest a well
>> specified and support architecture for running > 255 CPUs.
>
> Changing guest kernel will be big concern. I found commit ce69a784 did
> optimization to use X2APIC without IR in the guest when APIC id is less
> than 256 and so I proposed my idea to see everyone's feedback. Whether
> it's possible to relax the IR requirement when APIC id > 255 in the guest.
You can't do that easily because you can't address those additional CPUs
from *any* device then, only via IPIs. That means, Linux would have to
be changed to only set up IRQ affinity masks in the 0-254 range. I
suppose you would even have to patch tools like irqbalanced to not issue
mask changes via /proc that include larger CPU IDs. Practically not
feasible, already on Linux. Not to speak of other guest OSes.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2016-04-27 6:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 16:14 Enable more than 255 VCPU support without irq remapping function in the guest Lan, Tianyu
2016-04-26 16:17 ` Jan Kiszka
2016-04-26 16:49 ` Radim Krčmář
2016-04-27 4:10 ` Yang Zhang
2016-04-27 5:24 ` Jan Kiszka
2016-04-27 6:24 ` Lan Tianyu
2016-04-27 6:56 ` Jan Kiszka [this message]
2016-04-27 9:39 ` Yang Zhang
2016-04-27 9:45 ` Jan Kiszka
2016-04-28 1:11 ` Yang Zhang
2016-04-28 6:54 ` Jan Kiszka
2016-04-28 15:32 ` Radim Krčmář
2016-04-29 2:09 ` Yang Zhang
2016-04-29 3:01 ` Nadav Amit
2016-05-03 1:34 ` Yang Zhang
2016-04-29 4:59 ` Jan Kiszka
2016-05-03 1:52 ` Yang Zhang
2016-05-03 2:03 ` Nadav Amit
2016-05-03 4:55 ` Jan Kiszka
2016-05-04 1:46 ` Yang Zhang
2016-05-04 1:56 ` Nadav Amit
2016-05-04 5:38 ` Jan Kiszka
2016-04-27 5:39 ` Lan Tianyu
2016-04-27 14:38 ` Radim Krčmář
2016-04-27 5:15 ` Lan Tianyu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=572062B8.5030103@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=gleb@redhat.com \
--cc=imammedo@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=tianyu.lan@intel.com \
--cc=x86@kernel.org \
--cc=yang.zhang.wz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.