Anthony Liguori wrote:
>
> Yeah, I think this is a good point. If we're going to push the APIC
> into the kernel, we might as well put the PIT there too. The timing
> stuff is an absolute mess in QEMU since it wants to get a fast high
> res clock but isn't aware of things like CPU migration.
Ingo Molnar wrote:
> there is a remote possibility that some OSs depend on certain devices
> being level-triggered: for example if you get an IRQ from a
> level-triggered device and _dont_ deassert that signal from the IRQ
> handler (intentionally so), then the semantics of current hardware will
Ingo Molnar wrote:
> we should move all the PICs into KVM proper - and that includes the
> i8259A PIC too. Qemu-space drivers are then wired to pins on these PICs,
> but nothing in Qemu does vector generation or vector prioritization -
> that task is purely up to KVM. There are mixed i8259A+lapi
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> It still exists in userspace. Having the code duplication
>>> (especially when it's not the same code base) is unfortunate.
>>>
>> This remains true.
>>
>
> but it's the wrong argument. Of course there's duplicate
* Gregory Haskins ([EMAIL PROTECTED]) wrote:
> LAPICs can be remapped on a per-cpu basis via an MSR, whereas something
> like an IOAPIC is a system-wide resource.
Yes, I see now, no vcpu in kvm_io_device callbacks' context (admittedly,
I'm used to the Xen implementation ;-)
> >> +struct kvm_io_de
The attachment contains fixes based on the feedback from Chris.
Thanks Chris!
Regards,
-Greg
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index fceeb84..0e6eb04 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -236,6 +236,54 @@ struct kvm_pio_request {
int rep;
};
+str
On Wed, 2007-04-04 at 23:21 +0200, Ingo Molnar wrote:
> * Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> > But why is it a good thing to do PV drivers in the kernel? You lose
> > flexibility and functionality to gain performance. [...]
>
> in Linux a kernel-space network driver can still be tun
Hi Chris,
Thanks for the feedback. Ive answered inline below.
>>> On Wed, Apr 4, 2007 at 6:48 PM, in message
<[EMAIL PROTECTED]>, Chris Wright
<[EMAIL PROTECTED]> wrote:
> * Gregory Haskins ([EMAIL PROTECTED]) wrote:
>> The MMIO registration code has been broken out as a new patch from the
>
* Gregory Haskins ([EMAIL PROTECTED]) wrote:
> The MMIO registration code has been broken out as a new patch from the
> in-kernel APIC work with the following changes per Avi's request:
>
> 1) Supports dynamic registration
> 2) Uses gpa_t addresses
> 3) Explicit per-cpu mappings
>
> In addition,
>But why is it a good thing to do PV drivers in the kernel? You lose
>flexibility and functionality to gain performance. Really, it's more
>about there not being good enough userspace interfaces to do network
IO.
>
>> The lapic/PIC code
>> should also be available in Qemu for OSs that dont have
>> Gregory Haskins wrote:
>>
>>
>> Hmm. If the ioapic is in the kernel, then it's a platform- wide
resource
>> and you would need a vm ioctl. If ioapic emulation is in userspace,
>> then the ioapic logic will have decided which cpu is targeted and you
>> would issue a vcpu ioctl.
>>
>
>Thats exac
>we should move all the PICs into KVM proper - and that includes the
>i8259A PIC too. Qemu-space drivers are then wired to pins on these
PICs,
>but nothing in Qemu does vector generation or vector prioritization -
>that task is purely up to KVM. There are mixed i8259A+lapic models
>possible too and
Gregory Haskins wrote:
On Wed, Apr 4, 2007 at 4:32 PM, in message <[EMAIL PROTECTED]>,
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>>> My current thoughts are that we at least move the IOAPIC into the
>>> kernel as well. [...]
>>>
>> yes. And then do the final 10% mov
>Avi Kivity wrote:
>> Nakajima, Jun wrote:
>>> I compared the performance on Xen and KVM for kernel build using the
>>> same guest image. Looks like KVM was (kvm-17) three times slower as
>>> far as we tested, and that high load of qemu was one of the
>>> symptoms. We are looking at the shadow code
>
>Dor,
>
>Thanks, I realize there will certainly be a lot of work in
>virtualizing them. Maybe Intel can help out with VVT-x to give a
>root-root mode. ;)
>
>Any idea at a high level how vbox does it? I will post in their forum,
>but I assume somebody here has a good idea.
Vbox branched out from
>>> On Wed, Apr 4, 2007 at 4:32 PM, in message <[EMAIL PROTECTED]>,
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>> My current thoughts are that we at least move the IOAPIC into the
>> kernel as well. [...]
>
> yes. And then do the final 10% move of handling the i8529A in KVM too.
Hi Ingo,
We a
* Anthony Liguori <[EMAIL PROTECTED]> wrote:
> But why is it a good thing to do PV drivers in the kernel? You lose
> flexibility and functionality to gain performance. [...]
in Linux a kernel-space network driver can still be tunneled over
user-space code, and hence you can add arbitrary add-
The MMIO registration code has been broken out as a new patch from the
in-kernel APIC work with the following changes per Avi's request:
1) Supports dynamic registration
2) Uses gpa_t addresses
3) Explicit per-cpu mappings
In addition, I have added the concept of distinct VCPU and VM level
regi
* Gregory Haskins <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Attached is a snapshot of my current efforts on the kernel side for
> the in-kernel APIC work. Feedback welcome.
good work and nice patch! :)
> My current thoughts are that we at least move the IOAPIC into the
> kernel as well. [...
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> It still exists in userspace. Having the code duplication
>>> (especially when it's not the same code base) is unfortunate.
>>>
>> This remains true.
>>
>
> but it's the wrong argument. Of course there's duplicate
* Gregory Haskins <[EMAIL PROTECTED]> wrote:
> > pci is level triggered, so maybe the guests just handle the
> > inaccuracy.
> >
>
> Good point. I'm not sure how this works today. Perhaps we just get
> lucky that nothing checks the IRR in the IOAPIC coupled with a bug in
> the IOAPIC model
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > My current thoughts are that we at least move the IOAPIC into the
> > kernel as well. That will give sufficient control to generate ISA
> > bus interrupts for guests that understand APICs. If we want to be
> > able to generate ISA interrupts for le
* Anthony Liguori <[EMAIL PROTECTED]> wrote:
> > Keeping the apic in the kernel simplifies this with the cost of
> > maintaining an apic/pic implementation.
>
> Hrm, this is definitely starting to sound like a PITA to deal with.
> Maybe in-kernel platform devices are unavoidable :-/
yes, ver
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > It still exists in userspace. Having the code duplication
> > (especially when it's not the same code base) is unfortunate.
>
> This remains true.
but it's the wrong argument. Of course there's duplicate functionality,
and that's _good_ because it
Gregory Haskins wrote:
On Wed, Apr 4, 2007 at 10:20 AM, in message <[EMAIL PROTECTED]>,
> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>> The devices are already written to take a set_irq function. Instead of
>> hijacking the emulated PIC device, I think it would be better
Nakajima, Jun wrote:
> Avi Kivity wrote:
>
>> Nakajima, Jun wrote:
>>
>>> Most of H/W-virtualization capable processors out there don't support
>>> that feature today. I think the decision (kvm or qemu) should be done
>>> based on performance data. I'm not worried about maintenance issues;
>>> On Wed, Apr 4, 2007 at 1:43 PM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> Agreed. I was thinking that the interface for the "IOAPIC in kernel" model
> would look something like the way the pic_send_irq() function looks, except
> it wo
>>> On Wed, Apr 4, 2007 at 10:20 AM, in message <[EMAIL PROTECTED]>,
Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
> The devices are already written to take a set_irq function. Instead of
> hijacking the emulated PIC device, I think it would be better if in
> pc.c, we just conditionally created
Gregory Haskins wrote:
> Agreed. I was thinking that the interface for the "IOAPIC in kernel" model
> would look something like the way the pic_send_irq() function looks, except
> it would also convey BUS/IOAPIC id.
>
> so: kvm_inject_interrupt(int bus, int pin, int value);
>
> and the "kvmpic"
Avi Kivity wrote:
> Nakajima, Jun wrote:
>> I compared the performance on Xen and KVM for kernel build using the
>> same guest image. Looks like KVM was (kvm-17) three times slower as
>> far as we tested, and that high load of qemu was one of the
>> symptoms. We are looking at the shadow code, but
>>> On Wed, Apr 4, 2007 at 12:49 PM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>
>
> Hmm. If the ioapic is in the kernel, then it's a platform- wide resource
> and you would need a vm ioctl. If ioapic emulation is in userspace,
> then the i
Nakajima, Jun wrote:
> I compared the performance on Xen and KVM for kernel build using the
> same guest image. Looks like KVM was (kvm-17) three times slower as far
> as we tested, and that high load of qemu was one of the symptoms. We are
> looking at the shadow code, but the load of qemu looks v
Dor,
Thanks, I realize there will certainly be a lot of work in
virtualizing them. Maybe Intel can help out with VVT-x to give a
root-root mode. ;)
Any idea at a high level how vbox does it? I will post in their forum,
but I assume somebody here has a good idea.
Thanks.
On 4/4/07, Dor Laor <[EM
Anthony Liguori wrote:
>>
>>> BTW, I see CPU utilization of qemu is almost always 99% in the top
>>> command when I run kernel build in an x86-64 Linux guest.
>>>
>>
>
> qemu would be 99% even if all the time is being spent in the guest
> context.
>
> If the user time is high, an oprofile r
It seems from cursory inspection that this is possible in theory, even on HVM
hardware. My thoughts are as follows (Intel oriented, which I know better):
*) The hypervisor sets to trap on VMX type operations (VMXON/OFF/START/RESUME,
etc) and provide emulation of them as follows:
*) When a VMXO
Gregory Haskins wrote:
> What I was planning on doing was using that QEMU patch I provided to
> intercept all pic_send_irq() calls and forward them directly to the kernel
> via a new ioctl(). This ioctl would be directed at the VM fd, not the VCPU,
> since its a pure ISA global pin reference an
Avi Kivity wrote:
> Nakajima, Jun wrote:
>> Most of H/W-virtualization capable processors out there don't support
>> that feature today. I think the decision (kvm or qemu) should be done
>> based on performance data. I'm not worried about maintenance issues;
>> the APIC code is not expected to chan
>I swear this has been brought up before in this forum, but I can't
>find it. I'm curious what the virtualization gurus in this forum think
>of the possibilities for recursive virtualization. I know vbox claims
>to support it, but I haven't come across many details on how they do
>it and I don't th
Dor Laor wrote:
If we do this, then we can probably just handle the TPR as a special
case anyway and not bother returning to userspace when the TPR is
updated through MMIO. That saves the round trip without adding
emulation complexity.
>>> That means the emulation
Dor Laor wrote:
> This pushes towards in kernel apic too. Can't see how we avoid it.
>
>
Does it really? IIUC, we would avoid TPR traps entirely and would
just need to synchronize the TPR whenever we go down to userspace.
>>> It's a bit more comp
I swear this has been brought up before in this forum, but I can't
find it. I'm curious what the virtualization gurus in this forum think
of the possibilities for recursive virtualization. I know vbox claims
to support it, but I haven't come across many details on how they do
it and I don't think t
Nakajima, Jun wrote:
> Most of H/W-virtualization capable processors out there don't support
> that feature today. I think the decision (kvm or qemu) should be done
> based on performance data. I'm not worried about maintenance issues; the
> APIC code is not expected to change frequently. I'm a bit
Leslie Mann wrote:
I'll prepare the first patch. Can you ensure that your upgraded setup
still works kvm-17.
It does, as I use it daily in order to run a Win app that I need.
Please test the attached patch, against kvm-17. This is subversion
revision 4546 and git commit c01571ed5
This pushes towards in kernel apic too. Can't see how we avoid it.
>>>
>>> Does it really? IIUC, we would avoid TPR traps entirely and would
>>> just need to synchronize the TPR whenever we go down to userspace.
>>>
>>
>> It's a bit more complex than that, as userspace would need to
>>>
>>> If we do this, then we can probably just handle the TPR as a special
>>> case anyway and not bother returning to userspace when the TPR is
>>> updated through MMIO. That saves the round trip without adding
>>> emulation complexity.
>>
>> That means the emulation is split among user space a
>>> On Wed, Apr 4, 2007 at 3:40 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
>
> I would avoid moving down anything that's not strictly necessary.
Agreed.
>
> I still don't have an opinion as to whether it is necessary; I'll need
> to study the details. Xen pus
Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>>>
>>> This pushes towards in kernel apic too. Can't see how we avoid it.
>>>
>>
>> Does it really? IIUC, we would avoid TPR traps entirely and would
>> just need to synchronize the TPR whenever we go down to userspace.
>>
>
> It's a bit more co
Stephane
> > >There may be some propagation delay yet you, supposedly, do not suffer
> > >from masked
> > >interrupt windows. Also something to watch out for is that when you restore
> > >you must make sure that msrs upper bits are set to 1. Otherwise you may
> > >trigger
> > >unvoluntary interrup
Anthony Liguori wrote:
>>>
>>> If we do this, then we can probably just handle the TPR as a special
>>> case anyway and not bother returning to userspace when the TPR is
>>> updated through MMIO. That saves the round trip without adding
>>> emulation complexity.
>>
>> That means the emulation i
Avi Kivity wrote:
> Anthony Liguori wrote:
>>> Maybe some brave soul can hack kvm to patch the new instruction in
>>> place of the mmio instruction Windows uses to bang on the tpr.
>>
>> It seems like that shouldn't be too hard assuming that the MMIO
>> instructions are <= the new CR8 instruction
Anthony Liguori wrote:
>
>>
>> This pushes towards in kernel apic too. Can't see how we avoid it.
>>
>
> Does it really? IIUC, we would avoid TPR traps entirely and would
> just need to synchronize the TPR whenever we go down to userspace.
>
It's a bit more complex than that, as userspace wou
Anthony Liguori wrote:
>> Maybe some brave soul can hack kvm to patch the new instruction in
>> place of the mmio instruction Windows uses to bang on the tpr.
>
> It seems like that shouldn't be too hard assuming that the MMIO
> instructions are <= the new CR8 instruction. It would require knowi
Casey,
On Tue, Apr 03, 2007 at 10:46:38PM -0400, Casey Jeffery wrote:
> Stephane,
>
> I'm glad you found this; I thought I was going to have to repost while
> actually remembering to change the subject line.
>
Someone else pointed me to your message. The title was indeed misleading.
> >On Wed,
Dor Laor wrote:
This is for the TPR right? VT has special logic to handle TPR
virtualization doesn't it? I thought SVM did too...
>>> Yes, the TPR. Both VT and SVM virtualize CR8 in 64-bit mode. SVM
>>> also supports CR8 in 32-bit mode through a nwe instruction enco
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
Then again, are we really positive that we have to move the APIC
into the kernel? A lot of things will get much more complicated.
>>>
>>> The following arguments are in favor:
>>> - allow in-
>>> This is for the TPR right? VT has special logic to handle TPR
>>> virtualization doesn't it? I thought SVM did too...
>>>
>>
>> Yes, the TPR. Both VT and SVM virtualize CR8 in 64-bit mode. SVM
>> also supports CR8 in 32-bit mode through a nwe instruction encoding,
>> but
>> nobody uses that
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
Then again, are we really positive that we have to move the APIC
into the kernel? A lot of things will get much more complicated.
>>>
>>> The following arguments are in favor:
>>> - allow in
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>>
>>> Then again, are we really positive that we have to move the APIC
>>> into the kernel? A lot of things will get much more complicated.
>>
>> The following arguments are in favor:
>> - allow in-kernel paravirt drivers to i
Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> Then again, are we really positive that we have to move the APIC into
>> the kernel? A lot of things will get much more complicated.
>
> The following arguments are in favor:
> - allow in-kernel paravirt drivers to interrupt the guest without
> go
Anthony Liguori wrote:
>
> Then again, are we really positive that we have to move the APIC into
> the kernel? A lot of things will get much more complicated.
The following arguments are in favor:
- allow in-kernel paravirt drivers to interrupt the guest without going
through qemu (which involv
Avi Kivity wrote:
> Gregory Haskins wrote:
>> Hi Dor,
>> Please find a patch attached for your review which adds support for
>> dynamic substitution of the PIC/APIC code to QEMU. This will allow us
>> to selectively chose the KVM in-kernel apic emulation vs the QEMU
>> user-space apic emulatio
>Does KVM allow something like "memory hotplug" for its guests?
It does not support.
>
>
>For example, lets says you are running several guests, and would like
to
>start yet another one for a while - but have no free memory left.
>
We have another solution for it that will soon be pushed into th
Does KVM allow something like "memory hotplug" for its guests?
For example, lets says you are running several guests, and would like to
start yet another one for a while - but have no free memory left.
Obviously, your guests are so important that you don't want to stop them
- so you simply "h
Gregory Haskins wrote:
> My current thoughts are that we at least move the IOAPIC into the kernel as
> well. That will give sufficient control to generate ISA bus interrupts for
> guests that understand APICs. If we want to be able to generate ISA
> interrupts for legacy guests which talk to t
64 matches
Mail list logo
