Joerg Roedel wrote:
> Hi,
>
> here is the first release of patches for KVM to support the Nested
Paging
> (NPT) feature of AMD QuadCore CPUs for comments and public testing.
This
> feature improves the guest performance significantly. I measured an
> improvement of around 17% using kernbench in my
Joerg Roedel wrote:
> To disable the use of the Nested Paging feature even if it is
available in
> hardware this patch adds a module parameter. Nested Paging can be
disabled by
> passing npt=off to the kvm_amd module.
I think it's better to use a (common) parameter to qemu. That way you
can contro
Ryan Harper wrote:
> * Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
noticed
> > > > that whenever we launch
Anthony Liguori wrote:
> Ryan Harper wrote:
> > Playing around with running VMware-server within a KVM guest and
noticed
> > that whenever we launch a VM within the guest, KVM reports a GP
fault in
> > set_cr3. Removing the fault injection (raised for attempting to set
> > reserved bits) for the n
Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better
support
> live
> migration and SMP. It eliminates the hypercall page by trapping the
UD
> exception that would occur if you used the wrong hypercall instruction
for the
> underlying architecture and repla
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
>
> > Again, 0x4000 is not Xen specific. If the leaf 0x4000 is
used
> > for any guest to detect any hypervisor, that would be compelling
> > benefit. For future Xen-specific features, it's safe for Xen to use
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> >
> > I'm suggesting that we use CPUID.0x400Y (Y: TBD, e.g. 6) for
Linux
> > paravirtualization. The ebx, ecx and edx return the Linux
> > paravirtualization features available on that hypervisor. Those
features
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > The hypervisor detection machanism is generic, and the signature
> > returned is implentation specific. Having a list of all hypervisor
> > signatures sounds fine to me as we are detecting vendor-specific
> > proces
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Today, 3 CPUID leaves starting from 0x4000_ are defined in a
generic
> > fashion (hypervisor detection, version, and hypercall page), and
those
> > are the ones used by Xen today. We should extend those leaves (e
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > > > one. Start the kvm leaves at 0x40001000 or something?
> > > >
> > > >
> > > Yeah, that works with me.
> > >
> >
> > To me this is the beginning of fragmentation. W
Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> > > Yeah, see, the initial goal was to make it possible to use the KVM
> > > paravirtualizations on other hypervisors. However, I don't think
this
> > > is really going to be possible in general so maybe it's bet
Avi Kivity wrote:
> ron minnich wrote:
> > On 8/2/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> > > Li, Xin B wrote:
> > >
> > > > > Did you see any performance improvements out of this?
> > > > >
> > > > >
> > > > Acturally we don't expect any obviously performance because MSR
> > > > access
Gregory Haskins wrote:
> Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
> ---
>
> drivers/kvm/vmx.c | 71
> +++-- 1 files
changed, 58
> insertions(+), 13 deletions(-)
>
> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
> index 96837d6..86
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_CR
Li, Xin B wrote:
> > cpuid was intentionally made per-vcpu, since that's the way real
> > hardware works. Note that the ioctl() uses a vcpu fd, not a vm fd.
Is
> > there a reason why you can't initialize cpuid for all vcpus from
qemu?
> >
>
> To my knowledge, for a SMP system, all the CPU should
Jorge Lucángeli Obes wrote:
> Hi everyone. I'm again trying to get 32-bit Vista Ultimate to run as a
> guest on my 64-bit Core 2 Duo T5600. I'm using Xubuntu Feisty with a
> custom 2.6.20.3 kernel and kvm-26. Avi's WBINVD patch in kvm-26 got
> Vista not to generate real-mode errors anymore. However
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> > What I can say is that we (including the H/W teams) reviewed it
internally.
> >
>
> I've switched to using CPUID. I noticed that Xen also uses
0x40001
> so I'm presuming that that is okay too?
Yes.
>
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> > For KVM, it should be okay as well. But we can replace two CR4
accesses
> > with just one hypercall.
> >
>
> I was thinking the same thing :-)
>
> I was actually thinking about adding a hypercall to set/cl
Zachary Amsden wrote:
> Nakajima, Jun wrote:
> > And actually you don't need the write to CR3 to flush TLB because
the
> > one to CR4 does it. Or does kvm_flush_tlb_kernel assume that CR3 is
updated
> > at the same time?
> >
> > Jun
>
> It should no
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> > Anthony Liguori wrote:
> >
> > > Regards,
> > >
> > > Anthony Liguori
> > >
> >
> > I think we should use the CPUID instruction (leaf 0x4000) to
detect
> > the hypervosor
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
> > Sure. It adds a few more cycles onto native though (two memory
reads,
> > and some math).
>
> As opposed to a serializing control-register read? I think that's
> probably a win.
>
> J
>
And actually you don't need the write to CR3 to
Anthony Liguori wrote:
> Regards,
>
> Anthony Liguori
I think we should use the CPUID instruction (leaf 0x4000) to detect
the hypervosor as we are doing in Xen.
Jun
---
Intel Open Source Technology Center
-
This SF.net
Jorge Lucángeli Obes wrote:
> On 5/8/07, Nakajima, Jun <[EMAIL PROTECTED]> wrote:
> > Avi Kivity wrote:
> > > Jorge Lucángeli Obes wrote:
> > > > I have also tried using Windows Vista with kvm. Until now, I had (of
> > > > course) the same ACP
Dor Laor wrote:
> > > If you don't care about full virtualization kvm is the wrong
project for
> > > you. You might want to take a look at lguest.
> >
> > Ah, I had not realized that KVM was purely a full-virt environment
> > with no real use for PV-only users. I'll move on. Thanks for the
tip!
>
Avi Kivity wrote:
> Nakajima, Jun wrote:
> > I agree that it's straightforward to handle those page tables. The
> > question is interrupt remapping, i.e. how to inject particular
external
> > interupts to the vm that is reposible for the interrupts without
> > i
Avi Kivity wrote:
> Nakajima, Jun wrote:
> > An updated specification (Rev 1.0 update) of Intel(r) virtualization
> > technology for Directed I/O is now available on Intel web site:
> >
> >
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
&g
An updated specification (Rev 1.0 update) of Intel(r) virtualization
technology for Directed I/O is now available on Intel web site:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
rect_IO.pdf
The specification update includes DMA remapping capability, Interrupt
remappi
Avi Kivity wrote:
> Jorge Lucángeli Obes wrote:
>> I have also tried using Windows Vista with kvm. Until now, I had (of
>> course) the same ACPI problem as everybody. I had decided to compile
>> the new BIOS by hand. Imagine my suprise when I saw the third entry
>> in the above list =). I rushed to
This sounds good, but when will this get incorporated in the tree?
The reason I'm asking is that I've got X64 Vista up on KVM as well (with
patches to EFER and CR8 handling), and I'm wondering if I should hold on
because the code for CR8 handling would be different (and this in-kernel
APIC code w
andrzej zaborowski wrote:
> Hi,
>
> On 02/05/07, Nakajima, Jun <[EMAIL PROTECTED]> wrote:
>> Now I realized that I needed to use 32-bit Linux to build the
>> bios.bin (i.e. BIOS-bochs-latest) in bochs. As long as I used x86-64
>> Linux to build bios.bin, the res
Now I realized that I needed to use 32-bit Linux to build the bios.bin
(i.e. BIOS-bochs-latest) in bochs. As long as I used x86-64 Linux to
build bios.bin, the resulting binary had a problem, as I reported
previously.
With this very simple patch, I was able to install and run 32-bit Vista
on KVM (
Paul Brook wrote:
> On Monday 30 April 2007, Nakajima, Jun wrote:
>> We found a way to get 32-bit Vista up on KVM by fixing bios.bin. And
>> I think it should be helpful to qemu as well. However, I'm not sure
>> if the binary file has been created simply by applying
We found a way to get 32-bit Vista up on KVM by fixing bios.bin. And I
think it should be helpful to qemu as well. However, I'm not sure if the
binary file has been created simply by applying bios.diff to the latest
bochs CVS tree (actually I doubt it). Can somebody provide a recipe for
creating bi
Avi, Hi
I just tried the latest git tree, and I'm getting like (from
arch/x86_64/boot/setup.S):
Your CPU does not support long mode. Use a 32bit distribution.
I don't see the problem with kvm-20. I tried that quickly, so I can be
wrong. But can you please check that?
Thanks,
Jun
---
Intel Op
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 look
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;
>
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
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
I noticed that time proceeded twice as fast as the actual time in kvm-17
(not sure that it's a new issue, though). I used an x86-64 FC6 guest
(local and IO APIC, w/ ACPI).
Jun
---
Intel Open Source Technology Center
-
Take S
Avi Kivity wrote:
>
> I'd also like to add a read-only memory type so that apic reads can
> proceed natively rather than be emulated (the TODO has this now).
I don't understand how this can work. Instead, we should use the
hardware-based virtualization for the local APIC.
Jun
---
Intel Open Sour
Avi Kivity wrote:
> Nakajima, Jun wrote:
>> The key is the virtual MMU; getting bootstrap/IPI working is
>> straightforward.
>
> I'm glad to hear you say that.
>
>
>> Without NPT or EPT, we need to have an SMP-capable
>> shadow pagetable code. I thin
Avi Kivity wrote:
> Gregory Haskins wrote:
>> Hi all,
>> So what is the status of SMP support and is someone working on
>> this? I have some ideas about how to implement this and can spend
>> some time with it if it would be helpful. I just dont want to
>> duplicate efforts.
>>
>
> SMP is
42 matches
Mail list logo
