As we discussed, if we move APIC to kernel while leaving PIC in user
level, we have ABI level holes if the interrupt a user level qemu
injected is not immediately injected to guest for some reason. \
This patch fixes this by introducing new VM level IOCTL
KVM_SET_ISA_IRQ_LEVEL KVM_CREATE_PIC to
User level patch for in kernel PIC.
thx,eddie
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
kernel/Kbuild |2 +-
qemu/cpu-defs.h |1 +
qemu/hw/i8259.c |5 +
qemu/qemu-kvm.c |9 -
user/kvmctl.c | 44 +++-
Luca Tettamanti wrote:
When the old value and new one are the same the emulator skips the
write; this is undesiderable when the destination is a MMIO area and the
write shall be performed regardless of the previous value. This
optimization breaks e.g. a Linux guest APIC compiled without
Baruch Even wrote:
Anthony Liguori wrote:
Baruch Even wrote:
Luca wrote:
On 6/19/07, Baruch Even [EMAIL PROTECTED] wrote:
Hello,
I've tried to diff kvm-28 qemu directory with qemu 0.9.0 and I see
that
some files in the kvm sources have the content of the file
duplicated,
f.ex.
Sounds like a obvious bug to me. Other places doing tlb flush do the right
thing.
Signed-off-by: Shaohua Li [EMAIL PROTECTED]
Index: kvm-28/kernel/mmu.c
===
--- kvm-28.orig/kernel/mmu.c2007-06-20 16:52:46.0 +0800
+++
Shaohua Li wrote:
Sounds like a obvious bug to me. Other places doing tlb flush do the right
thing.
Right. Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
With KVM-28, attempting to install SLES 10 x86_64 from its DVD gives a
blank black screen as soon as the installer switches from text mode, after
the kernel has booted and the text-mode non-interactive part of yast has
run: the window resizes from the text mode size, and is redrawn black, and
Zachary Amsden wrote:
For software-reliant paravirtualization, it is difficult to atomically
switch from natural instructions to simulated para-instructions on the
fly; you would need stop_machine_run that also holds off NMIs (so as
to keep IF flag state intact across a window where
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of paravirt_ops
implementations and they aren't large so I don't think there's a big
Avi Kivity wrote:
Shaohua Li wrote:
Sounds like a obvious bug to me. Other places doing tlb flush do the
right
thing.
Right. Applied, thanks.
BTW,
The current VMX code does not make sense to me:
static void vmx_flush_tlb(struct kvm_vcpu *vcpu)
{
vmcs_writel(GUEST_CR3,
Zachary Amsden wrote:
For a VMM which supports both full emulation and para-virtualization,
testing CPUID leaves is not sufficient to determine applicability of a
paravirt device driver. This only indicates the presence of the
functionality, not the fact that the functionality has been
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of paravirt_ops
implementations
Anthony Liguori wrote:
Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I don't agree that having paravirt_ops within a normal module is all
that useful. By the time modules can be loaded, the kernel has
completely booted. There should only be a handful of
Zachary Amsden wrote:
Basically, it just makes it easier on distributors and allows any old
kernel with paravirt-ops module support to run on any modern, new
hypervisor - that might not have even existed at the time the distro
was created.
Hey, isn't that what VMI's for? ;)
I'd been
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Basically, it just makes it easier on distributors and allows any old
kernel with paravirt-ops module support to run on any modern, new
hypervisor - that might not have even existed at the time the distro
was created.
Hey, isn't that what
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you
Anthony Liguori wrote:
Zachary Amsden wrote:
Anthony Liguori wrote:
But what's the value in having it not in the kernel? Let's take Xen
and lhype out of the picture because it clearly has to be there for
them. You have a little less in the kernel now but then your kernel
boots more
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you
Jeremy Fitzhardinge wrote:
Hm, you need to quiesce the kernel in some way when you do a migrate,
so making sure it isn't in a hypercall would be just part of that. In
general you'd make sure all but one CPU is parked somewhere, and the
remaining CPU is doing the suspend, right?
The
Zachary Amsden wrote:
Unless you also migrate the hypercall page itself and impose migration
restrictions on compatible hypercall pages.
Seems unreasonable, especially if you support migration between VT and
SVM machines. The whole point of a hypercall page is to give you a
point of
Zachary Amsden wrote:
You only need to quiesce if you have guest-visible data-structures
that have details about the underlying hardware. So Xen needs to
quiesce, but I don't know of any other VMM that would.
VMI, KVM and lhype should be capable of transparent migration without
guest
Zachary Amsden wrote:
Yes, but if we want to stay with that forward compatibility story, we
need a way to allow paravirt device probing to be completely
orthogonal to paravirt-ops probing. Either the VMware hypervisor
needs to NOT implement a CPUID leaf, keeping the same ROM based
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Unless you also migrate the hypercall page itself and impose
migration restrictions on compatible hypercall pages.
Seems unreasonable, especially if you support migration between VT and
SVM machines. The whole point of a hypercall page is
On 6/20/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
I'm not wildly happy about the idea of using PCI for probing for
otherwise completely non-PCI devices,
Good :-)
Xen deals with it with Xenbus, but I
figure I'm unlikely to convince everyone to adopt that.
Especially those of us who
Jeremy Fitzhardinge wrote:
The completely identical device model is of course ideal, but the
implementation and consolidation of that is a long term prospect to
move towards, not something that will happen immediately. We at least
emulate physical hardware devices already, and will continue
Zachary Amsden wrote:
If I had a gentoo install,
Yes, but then you'd be a gentoo user. ;)
I would probably go so far as to want to recompile everything after
migration across CPU vendors; things like NMIs, MSRs, thermal controls
and sleep states are also vendor dependent and either need to
Avi,
On Fri, Jun 15, 2007 at 01:49:06PM +0300, Avi Kivity wrote:
Magicboiz wrote:
a little bit better. It Opps'ed again, but this time, my laptop is still
usable:
sudo /usr/local/kvm/bin/qemu -hda /tmp/disco-qemu -m 128 -boot d
-cdrom /tmp/debian-40r0-i386-businesscard.iso -vnc :3
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will
Anthony Liguori wrote:
The real trick is doing it without the guest being involved at all.
Right now, it won't be a problem in KVM since the hypercall page only
differs by a single instruction across platforms. In the future,
we'll have to be smarter and wait for all VCPUs to leave the
Zachary Amsden wrote:
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change
BTW,
The current VMX code does not make sense to me:
static void vmx_flush_tlb(struct kvm_vcpu *vcpu)
{
vmcs_writel(GUEST_CR3, vmcs_readl(GUEST_CR3));
}
The point is, vmexits will invalidate all TLB entries on Intel VT
processor today.
-Xin
Hi,
This is an update to the paravirt_ops KVM backend series. I've made a
number of changes and attempted to incorporate all the feedback from the
last review. Some highlights:
1) Clean up the paravirt time source patch to use a more Xen-like model
2) Change the hypercall queueing to pass a
Regards,
Anthony Liguori
Subject: [PATCH] KVM paravirt_ops core infrastructure
Author: Anthony Liguori [EMAIL PROTECTED]
This patch implements paravirt_ops support for KVM and updates the current
paravirtualization support in KVM to match. Some changes to the previous
paravirtualization
This helps a lot on modern kernels where Linux is much more finicky
about using the TSC as a time source.
Regards,
Anthony Liguori
Subject: [PATCH] KVM: paravirt time source
Author: Anthony Liguori [EMAIL PROTECTED]
This patch implements a paravirtual time source based on a new field added to
Regards,
Anthony Liguori
Subject: [PATCH] KVM: Implement CR read caching for KVM paravirt_ops
Author: Anthony Liguori [EMAIL PROTECTED]
With hardware virtualization, CR reads often times require a VMEXIT which is
rather expensive. Instead of reading CR and taking the VMEXIT, maintain a
copy of
Regards,
Anthony Liguori
Subject: [PATCH] KVM: Add paravirt MMU write support
Author: Anthony Liguori [EMAIL PROTECTED]
On at least AMD hardware, hypercall based manipulation of page table memory
is significantly faster than taking a page fault. Additionally, using
hypercalls to manipulation
Regards,
Anthony Liguori
Subject: [PATCH] KVM: Add hypercall queue for paravirt_ops implementation
Author: Anthony Liguori [EMAIL PROTECTED]
Implemented a hypercall queue that can be used when paravirt_ops lazy mode
is enabled. This patch enables queueing of MMU write operations and CR
Anthony Liguori wrote:
As usual, the latest bits are available at
http://hg.codemonkey.ws/kvm-paravirt
I neglected to mention that the major missing piece right now is
save/restore support. Since the VMCA is set with an MSR, I think I can
just expose this MSR to userspace and add another
One of the things that I noticed during the development of the APIC
patchset that was quite odd:
1) Linux guest was programming the PIT for 4ms.
2) QEMU was programming the sigalarm for 1ms
3) SIGALARM was only delivered every 8ms (probably maximum resolution
with this setup) so the timer-wheel
39 matches
Mail list logo
