VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in
On 03/12/2014 00:05, Radim Krčmář wrote:
> 2014-12-02 14:09+0100, Paolo Bonzini:
>> - EAX=0Dh, ECX=1: output registers EBX/ECX/EDX are reserved.
>
> (As good as reserved without XSAVES/IA32_XSS.)
>
>> - EAX=0Dh, ECX>1: output register ECX is zero for all the CPUID leaves
>> we support, because
Hi all,
On 12/02/2014 01:43 PM, Paolo Bonzini wrote:
On 02/12/2014 13:16, Eric S. Johansson wrote:
I got win7 installed, virtio devices working and took forever to trickle
in updates because of a w7 bug update manager bug that take up all cpu
resources. now I got DNS 13 installed but I'm get
On 12/3/2014 3:21 AM, Hans de Goede wrote:
Hi all,
On 12/02/2014 01:43 PM, Paolo Bonzini wrote:
On 02/12/2014 13:16, Eric S. Johansson wrote:
I got win7 installed, virtio devices working and took forever to
trickle
in updates because of a w7 bug update manager bug that take up all cpu
reso
On 03/12/2014 03:36, Wanpeng Li wrote:
> Add xsaves related definition, it also adds corresponding part
> to kvm_get/put, and vmstate.
>
> Signed-off-by: Wanpeng Li
> ---
> v1 -> v2:
> * use a subsection instead of bumping the version number.
>
> target-i386/cpu.h | 2 ++
> target-i386
Hi,
On 12/03/2014 09:31 AM, Eric S. Johansson wrote:
On 12/3/2014 3:21 AM, Hans de Goede wrote:
Hi all,
On 12/02/2014 01:43 PM, Paolo Bonzini wrote:
On 02/12/2014 13:16, Eric S. Johansson wrote:
I got win7 installed, virtio devices working and took forever to trickle
in updates because of
Hi Juan, is this for the 9th, or did I get the day wrong
Anyway - I would like to talk about Multi-core - a huge thank you to everybody
for your feedback, we’ll be starting work on this, and I’d like to bring a
proposal in terms of the path we’ll take and get consensus on the first steps.
Cheer
On 02/12/2014 23:22, Chris J Arges wrote:
> In emulator.c/tests_smsw, smsw (3) fails because h_mem isn't being set
> correctly
> before smsw is called. By declaring the h_mem function parameter as volatile,
> the compiler no longer optimizes out the assignment before smsw.
>
> Signed-off-by: Ch
On 12/3/2014 3:52 AM, Hans de Goede wrote:
Eric are you using usb-host redirection, or Spice's usb network redir ?
Host redirection I assume. It was from the collection of devices UI
and I added the device to pass through from the list of host USB
devices.
Ok, then Gerd is probably the bes
On Tue, 2 Dec 2014 21:03:45 +0200
"Michael S. Tsirkin" wrote:
> On Tue, Dec 02, 2014 at 04:41:36PM +0100, Cornelia Huck wrote:
> > void virtio_queue_set_num(VirtIODevice *vdev, int n, int num)
> > {
> > +/*
> > + * For virtio-1 devices, the number of buffers may only be
> > + * upda
Hi,
> >>> I pass throught the usb audio device (logitech h800 USB 046d:0a29) and
> >>> it is seen as a device in windows. then I hear the headset sync-up
> >>> beeps and the device vanishes from windows. pointers as to what I
> >>> should look at next?
> >>
> >> Adding back Hans and Gerd...
>
Hi,
EXIT_REASON_EPT_VIOLATION's corresponding handle is handle_ept_violation(),
and EXIT_REASON_EPT_MISCONFIG's corresponding handle is handle_ept_misconfig(),
what's the difference between them?
I read the SDM-3C 28.2.3 EPT-Induced VM Exits, and found below description,
"An EPT misconfiguration
On Wed, 3 Dec 2014 10:27:36 +0100
Cornelia Huck wrote:
> On Tue, 2 Dec 2014 21:03:45 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Tue, Dec 02, 2014 at 04:41:36PM +0100, Cornelia Huck wrote:
> > > void virtio_queue_set_num(VirtIODevice *vdev, int n, int num)
> > > {
> > > +/*
> > > + *
On Wed, Dec 03, 2014 at 05:50:33PM +0800, Zhang Haoyu wrote:
> Hi,
>
> EXIT_REASON_EPT_VIOLATION's corresponding handle is handle_ept_violation(),
> and EXIT_REASON_EPT_MISCONFIG's corresponding handle is
> handle_ept_misconfig(),
> what's the difference between them?
>
> I read the SDM-3C 28.2.
> > Hi,
> >
> > EXIT_REASON_EPT_VIOLATION's corresponding handle is handle_ept_violation(),
> > and EXIT_REASON_EPT_MISCONFIG's corresponding handle is
> > handle_ept_misconfig(),
> > what's the difference between them?
> >
> > I read the SDM-3C 28.2.3 EPT-Induced VM Exits, and found below descr
Hi All,
I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 VM
installation was fine, but it does random reboot by itself, the error
code is 0x0101, does anyone know how to fix this?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord.
On Wed, Dec 03, 2014 at 06:12:10PM +0800, Zhang Haoyu wrote:
> > > Hi,
> > >
> > > EXIT_REASON_EPT_VIOLATION's corresponding handle is
> > > handle_ept_violation(),
> > > and EXIT_REASON_EPT_MISCONFIG's corresponding handle is
> > > handle_ept_misconfig(),
> > > what's the difference between the
> Hi All,
>
> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 VM
> installation was fine, but it does random reboot by itself, the error
> code is 0x0101, does anyone know how to fix this?
Could you try hv_relaxed, like "-cpu kvm64,hv_relaxed".
Thanks,
Zhang Haoyu
--
To unsubsc
On 03/12/2014 11:12, Zhang Haoyu wrote:
>> > EXIT_REASON_EPT_VIOLATION is similar to a "page not present" pagefault
>> > EXIT_REASON_EPT_MISCONFIG is similar to a "reserved bit set" pagefault.
>> > handle_ept_misconfig() handles mmio pagefault because KVM has an
>> > optimization that uses reserv
On Tue, Dec 02, 2014 at 05:50:00PM +, Peter Maydell wrote:
> On 2 December 2014 at 17:27, Eric Auger wrote:
> > Since the advent of dynamic initialization of VGIC, this latter is
> > initialized very late, on the first vcpu run. This initialization
> > could be initiated much earlier by the us
Hi,
How do I know if my qemu-kvm version support this?
On Wed, Dec 3, 2014 at 6:25 PM, Zhang Haoyu wrote:
>> Hi All,
>>
>> I am running 3.13.0-24-generic kernel on Ubuntu 14, Windows 7 VM
>> installation was fine, but it does random reboot by itself, the error
>> code is 0x0101, does anyone
On Tue, Dec 02, 2014 at 06:27:31PM +0100, Eric Auger wrote:
> Since the advent of dynamic initialization of VGIC, this latter is
> initialized very late, on the first vcpu run. This initialization
> could be initiated much earlier by the user, as soon as it has
> provided the requested dimensioning
On Wed, Dec 03, 2014 at 10:50:04AM +0100, Cornelia Huck wrote:
> On Wed, 3 Dec 2014 10:27:36 +0100
> Cornelia Huck wrote:
>
> > On Tue, 2 Dec 2014 21:03:45 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > On Tue, Dec 02, 2014 at 04:41:36PM +0100, Cornelia Huck wrote:
> > > > void virtio_queue_s
https://bugzilla.redhat.com/show_bug.cgi?id=893857
In fact I am doing testing now, but are we fixing one problem and
introduce other problem?!
On Wed, Dec 3, 2014 at 6:36 PM, Thomas Lau wrote:
> Hi,
>
> How do I know if my qemu-kvm version support this?
>
> On Wed, Dec 3, 2014 at 6:25 PM, Zhang
> Hi,
>
> How do I know if my qemu-kvm version support this?
>
I don't know which qemu version starts to support hv-relaxed,
but I'm sure qemu-1.4.1 and later versions support it.
qemu will report error if it dosen't support it.
Please show your qemu version.
Thanks,
Zhang Haoyu
hv-relaxed was
qemu-system-x86_64 -version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.7), Copyright
(c) 2003-2008 Fabrice Bellard
On Wed, Dec 3, 2014 at 7:01 PM, Zhang Haoyu wrote:
>> Hi,
>>
>> How do I know if my qemu-kvm version support this?
>>
> I don't know which qemu version starts to suppor
> https://bugzilla.redhat.com/show_bug.cgi?id=893857
>
> In fact I am doing testing now, but are we fixing one problem and
> introduce other problem?!
>
I'm not sure about this, but it works on my side,
I think BSOD(error:0x0078) has been fixed,
please show your environment.
Thanks,
Zhang Ha
"it works on your side" meaning that you had such issue but afterwards
it's all fixed by apply hv_relaxed ?
On Wed, Dec 3, 2014 at 7:08 PM, Zhang Haoyu wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=893857
>>
>> In fact I am doing testing now, but are we fixing one problem and
>> introduce
On Wed, 3 Dec 2014 12:52:51 +0200
"Michael S. Tsirkin" wrote:
> On Wed, Dec 03, 2014 at 10:50:04AM +0100, Cornelia Huck wrote:
> > diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
> > index 43b7e02..1e2a720 100644
> > --- a/hw/virtio/virtio-mmio.c
> > +++ b/hw/virtio/virtio-mmio.c
On Wed, Dec 03, 2014 at 12:14:10PM +0100, Cornelia Huck wrote:
> On Wed, 3 Dec 2014 12:52:51 +0200
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Dec 03, 2014 at 10:50:04AM +0100, Cornelia Huck wrote:
>
> > > diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
> > > index 43b7e02..1e2a72
If you run WS2008(R2) or Win7 - always turn on relaxed timing. Otherwise
it's just a matter of time when you hit 101 BOSD.
Bugcheck 78 is quite rare one. What is your setup, and how easy it's
reproducible?
Best regards,
Vadim.
On Wed, 2014-12-03 at 19:13 +0800, Thomas Lau wrote:
> "it works on y
Oh I see,
So 101 BSOD problem is well known? Can't find any document mention about 101
BSOD online.
I tried to use hv_ other options but Win7 can't boot up properly and stucked at
starting Windows screen.
Sent from my BlackBerry 10 smartphone.
Original Message
From: Vadim Rozenfeld
Sent:
On Wed, 3 Dec 2014 13:19:17 +0200
"Michael S. Tsirkin" wrote:
> On Wed, Dec 03, 2014 at 12:14:10PM +0100, Cornelia Huck wrote:
> > On Wed, 3 Dec 2014 12:52:51 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Dec 03, 2014 at 10:50:04AM +0100, Cornelia Huck wrote:
> > > > @@ -748,6 +756,1
2014-12-03 09:04+0100, Paolo Bonzini:
> On 03/12/2014 00:05, Radim Krčmář wrote:
> > 2014-12-02 14:09+0100, Paolo Bonzini:
> >> + } else {
> >> + if (entry[i].eax == 0 || !(supported & mask))
> >> + continue;
> >> +
On 03/12/2014 13:07, Radim Krčmář wrote:
>> > Well, there is a WARN just above. :) But I can change it to zero instead.
> Yeah, I wasn't sure about the WARN ... I can only see it trigger after
> host xcr0 changes and we are much more screwed in that case anyway :)
> (But it has a chance of catch
> This series improves yielding on architectures that cannot disable preemption
> while entering the guest and makes the creating thread of a VCPU the owning
> thread and therefore the yield target when yielding to that VCPU.
>
> We should focus on the case creating thread == executing thread and
On Wed, 2014-12-03 at 19:36 +0800, t...@tetrioncapital.com wrote:
> Oh I see,
>
> So 101 BSOD problem is well known? Can't find any document mention about 101
> BSOD online.
>
http://msdn.microsoft.com/en-us/library/windows/hardware/ff557211%
28v=vs.85%29.aspx
> I tried to use hv_ other opti
2014-12-02 19:21+0800, Wanpeng Li:
> Exporse intel xsaves feature to guest.
0xD.1:ebx ought to be non-zero with XSAVES, even if IA32_XSS is known to
be 0, so we'll need to set it after Paolo's patch.
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/cpuid.c | 3 ++-
> 1 file changed, 2 insertion
On 28/11/2014 12:40, Raghavendra K T wrote:
> I am seeing very small improvement in <= 1x commit cases
> and for >1x overcommit, a very slight regression. But considering the
> test environment noises, I do not see much effect from the
> patch.
I think these results are the only one that could b
On 03/12/2014 13:12, David Hildenbrand wrote:
>> This series improves yielding on architectures that cannot disable preemption
>> while entering the guest and makes the creating thread of a VCPU the owning
>> thread and therefore the yield target when yielding to that VCPU.
>>
>> We should focus
On 25/11/2014 17:04, David Hildenbrand wrote:
> @@ -124,15 +124,6 @@ int vcpu_load(struct kvm_vcpu *vcpu)
>
> if (mutex_lock_killable(&vcpu->mutex))
> return -EINTR;
> - if (unlikely(vcpu->pid != current->pids[PIDTYPE_PID].pid)) {
> - /* The thread running th
>
>
> On 03/12/2014 13:12, David Hildenbrand wrote:
> >> This series improves yielding on architectures that cannot disable
> >> preemption
> >> while entering the guest and makes the creating thread of a VCPU the owning
> >> thread and therefore the yield target when yielding to that VCPU.
> >>
On 25/11/2014 17:04, David Hildenbrand wrote:
> As some architectures (e.g. s390) can't disable preemption while
> entering/leaving the guest, they won't receive the yield in all situations.
>
> kvm_enter_guest() has to be called with preemption_disabled and will set
> PF_VCPU. After that point
Am 03.12.2014 um 13:54 schrieb Paolo Bonzini:
>
>
> On 03/12/2014 13:12, David Hildenbrand wrote:
>>> This series improves yielding on architectures that cannot disable
>>> preemption
>>> while entering the guest and makes the creating thread of a VCPU the owning
>>> thread and therefore the yie
> Applied with a rewritten commit message:
>
> KVM: don't check for PF_VCPU when yielding
>
> kvm_enter_guest() has to be called with preemption disabled and will
> set PF_VCPU. Current code takes PF_VCPU as a hint that the VCPU thread
> is running and therefore needs no yield.
>
> However, th
On 03/12/2014 14:00, Christian Borntraeger wrote:
> Am 03.12.2014 um 13:54 schrieb Paolo Bonzini:
>>
>>
>> On 03/12/2014 13:12, David Hildenbrand wrote:
This series improves yielding on architectures that cannot disable
preemption
while entering the guest and makes the creating th
On 05/08/2014 16:44, Christian Borntraeger wrote:
> We currently track the pid of the task that runs the VCPU in
> vcpu_load. Since we call vcpu_load for all kind of ioctls on a
> CPU, this causes hickups due to synchronize_rcu if one CPU is
> modified by another CPU or the main thread (e.g. init
This is the size of the XSAVES area. This completes guest support
for XSAVES (with no support yet for supervisor states, i.e. XSS == 0
always in guests for now).
Suggested-by: Radim Krčmář
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/cpuid.c | 13 +
1 file changed, 9 insertions(+)
The final thing to do, besides adding support for XSS != 0, is to set
CPUID(EAX=0xd,ECX=1).EBX to the size of the XSAVES area.
Paolo Bonzini (2):
KVM: x86: use F() macro throughout cpuid.c
KVM: x86: set CPUID(EAX=0xd,ECX=1).EBX correctly
arch/x86/kvm/cpuid.c | 27 ---
For code that deals with cpuid, this makes things a bit more readable.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/cpuid.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index d82204ac555e..2c561dba81c0 100644
---
2014-12-03 14:40+0100, Paolo Bonzini:
> This is the size of the XSAVES area. This completes guest support
> for XSAVES (with no support yet for supervisor states, i.e. XSS == 0
> always in guests for now).
>
> Suggested-by: Radim Krčmář
> Signed-off-by: Paolo Bonzini
> ---
Reviewed-by: Radim K
Paolo Bonzini wrote:
> Userspace is expecting non-compacted format for KVM_GET_XSAVE, but
> struct xsave_struct might be using the compacted format. Convert
> in order to preserve userspace ABI.
>
> Likewise, userspace is passing non-compacted format for KVM_SET_XSAVE
> but the kernel will pass
Thanks for the link,
Here is my qemu command line:
qemu-system-x86_64 -enable-kvm -name test_server_Windows1 -S -machine
pc-i440fx-trusty,accel=kvm,usb=off -cpu
SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pb
On 03/12/2014 15:23, Nadav Amit wrote:
> I think it is better just to replace the last line with:
>
> *(u64 *)(dest + XSAVE_HDR_OFFSET) = xsave->xsave_hdr.xstate_bv
Right, this matches
u64 xstate_bv = *(u64 *)(src + XSAVE_HDR_OFFSET);
...
xsave->xsave_hdr.xstate_bv = xs
On 01/12/2014 14:40, Vasiliy Tolstov wrote:
>> > Hello. I found some issues with enable_apicv=Y and freebsd, does this
>> > problem solved or no?
>> > I'm have latest linux 3.10.x.
>
> Also i'm succeseful run freebsd 10 with 1Gb memory, but failed to boot
> with 4gb memory.
> But in this case i
the link that I was trying to follow and Win7 bootup stuck is this:
http://blog.wikichoon.com/2014/07/enabling-hyper-v-enlightenments-with-kvm.html
On Wed, Dec 3, 2014 at 10:51 PM, Thomas Lau wrote:
> Thanks for the link,
>
> Here is my qemu command line:
> qemu-system-x86_64 -enable-kvm -name te
On 12/3/2014 3:52 AM, Hans de Goede wrote:
Eric are you using usb-host redirection, or Spice's usb network redir ?
This little bit of time this morning learning about spice and the
network redirection. It worked for about half an hour and then failed in
the same way the host redirection fai
In emulator.c/tests_smsw, smsw (3) fails because h_mem isn't being set correctly
before smsw is called. By using the + constraint modifier for memory we can
ensure the compiler no longer optimizes out the assignment before smsw.
Signed-off-by: Chris J Arges
---
x86/emulator.c | 2 +-
1 file chan
On 03/12/2014 16:44, Chris J Arges wrote:
> In emulator.c/tests_smsw, smsw (3) fails because h_mem isn't being set
> correctly
> before smsw is called. By using the + constraint modifier for memory we can
> ensure the compiler no longer optimizes out the assignment before smsw.
>
> Signed-off-b
on arm/arm64 the VGIC is dynamically instantiated and it is useful
to expose its state, especially for irqfd setup.
This patch defines __KVM_HAVE_ARCH_VIRTUAL_INTC_INITIALIZED
and implements kvm_arch_is_virtual_intc_initialized
Signed-off-by: Eric Auger
---
arch/arm/include/asm/kvm_host.h | 6
On arm/arm64, the interrupt controller is dynamically instantiated.
There is a risk the user-space assigns an irqfd before this latter
is initialized and ready to accept virtual irq injection. On such
attempt, the IRQFD setup is rejected and -EAGAIN is returned.
Signed-off-by: Eric Auger
---
vir
This patch enables irqfd on arm/arm64.
Both irqfd and resamplefd are supported. Injection is implemented
in vgic.c without routing.
This patch enables CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQFD.
KVM_CAP_IRQFD is now advertised. KVM_CAP_IRQFD_RESAMPLE capability
automatically is advertised
On 28/11/2014 12:59, Zhang, Yang Z wrote:
>
> According the feedback from Haoyu on my test patch which skipping the
> interrupt injection if irq line is active (See another thread), it seems
> QEMU does not follow the rule. But my patch is just a workaround. I
> guess we should have more though
This patch series enables irqfd on arm and arm64.
Irqfd framework enables to inject a virtual IRQ into a guest upon an
eventfd trigger. User-side uses KVM_IRQFD VM ioctl to provide KVM with
a kvm_irqfd struct that associates a VM, an eventfd, a virtual IRQ number
(aka. the gsi). When an actor sign
Introduce __KVM_HAVE_ARCH_VIRTUAL_INTC_INITIALIZED define and
associated kvm_arch_is_virtual_intc_initialized function. This latter
allows to test whether the virtual interrupt controller is initialized
and ready to accept virtual IRQ injection. On some architectures,
the virtual interrupt controll
CONFIG_HAVE_KVM_IRQCHIP is needed to support IRQ routing (along
with irq_comm.c and irqchip.c usage). This is not the case for
arm/arm64 currently.
This patch unsets the flag for both arm and arm64.
Signed-off-by: Eric Auger
Acked-by: Christoffer Dall
Acked-by: Will Deacon
---
arch/arm/kvm/Kc
2014-12-03 15:26+0100, Paolo Bonzini:
>
>
> On 03/12/2014 15:23, Nadav Amit wrote:
> > I think it is better just to replace the last line with:
> >
> > *(u64 *)(dest + XSAVE_HDR_OFFSET) = xsave->xsave_hdr.xstate_bv
Yeah, or we can use this value for xstate_bv to save some copying too,
diff --g
On Wed, Dec 03, 2014 at 05:37:51AM +0100, Juergen Gross wrote:
> On 12/03/2014 03:28 AM, Luis R. Rodriguez wrote:
>> On Tue, Dec 02, 2014 at 11:11:18AM +, David Vrabel wrote:
>>> On 01/12/14 22:36, Luis R. Rodriguez wrote:
Then I do agree its a fair analogy (and find this obviously od
When userspace resets the vcpu using KVM_ARM_VCPU_INIT, we should also
reset the HCR, because we now modify the HCR dynamically to
enable/disable trapping of guest accesses to the VM registers.
This is crucial for reboot of VMs working since otherwise we will not be
doing the necessary cache maint
It is not clear that this ioctl can be called multiple times for a given
vcpu. Userspace already does this, so clarify the ABI.
Also specify that userspace is expected to always make secondary and
subsequent calls to the ioctl with the same parameters for the VCPU as
the initial call (which users
If a VCPU was originally started with power off (typically to be brought
up by PSCI in SMP configurations), there is no need to clear the
POWER_OFF flag in the kernel, as this flag is only tested during the
init ioctl itself.
Signed-off-by: Christoffer Dall
---
arch/arm/kvm/arm.c | 2 +-
1 file
Introduce a new function to unmap user RAM regions in the stage2 page
tables. This is needed on reboot (or when the guest turns off the MMU)
to ensure we fault in pages again and make the dcache, RAM, and icache
coherent.
Using unmap_stage2_range for the whole guest physical range does not
work,
The implementation of KVM_ARM_VCPU_INIT is currently not doing what
userspace expects, namely making sure that a vcpu which may have been
turned off using PSCI is returned to its initial state, which would be
powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag.
Implement the expec
Several people have reported problems with rebooting ARM VMs, especially
on 32-bit ARM. This is mainly due to the same reason we were seeing
boot errors in the past, namely that the ram, dcache, and icache weren't
coherent on guest boot with the guest (stage-1) MMU disabled. We solved
this by ens
When a vcpu calls SYSTEM_OFF or SYSTEM_RESET with PSCI v0.2, the vcpus
should really be turned off for the VM adhering to the suggestions in
the PSCI spec, and it's the sane thing to do.
Also, clarify the behavior and expectations for exits to user space with
the KVM_EXIT_SYSTEM_EVENT case.
Signe
On 12/01/2014 08:27 AM, Paolo Bonzini wrote:
>
>
> On 29/11/2014 16:27, Eugene Korenevsky wrote:
>> Signed-off-by: Eugene Korenevsky
>> ---
>>
>> Notes:
>> This patch adds checks on Guest RIP specified in Intel Software
>> Developer Manual.
>>
>> The following checks are performed
This patch adds trace points in the guest entry and exit code and also
for exceptions handled by the host in kernel mode - hypercalls and page
faults. The new events are added to /sys/kernel/debug/tracing/events
under a new subsystem called kvm_hv.
Acked-by: Paul Mackerras
Signed-off-by: Suresh W
> Oh I see,
>
> So 101 BSOD problem is well known? Can't find any document mention about 101
> BSOD online.
>
> I tried to use hv_ other options but Win7 can't boot up properly and stucked
> at starting Windows screen.
>
Could you confirm that the stuck was caused by vhich hv feature?
The co
Hi,
I don't want to recompile stuff, does it matter to have hv_vapic on at all?
On Thu, Dec 4, 2014 at 9:24 AM, Zhang Haoyu wrote:
>> Oh I see,
>>
>> So 101 BSOD problem is well known? Can't find any document mention about 101
>> BSOD online.
>>
>> I tried to use hv_ other options but Win7 can'
[adding potentially interested people]
On Fri, Nov 7, 2014 at 3:58 PM, Andy Lutomirski wrote:
> The syscall exit asm is a big mess. There's a really fast path, some
> kind of fast path code (with a hard-coded optimization for audit), and
> the really slow path. The result is that it's very hard
I just confirmed that vapic is causing win7 stuck.
On Thu, Dec 4, 2014 at 9:34 AM, Thomas Lau wrote:
> Hi,
>
> I don't want to recompile stuff, does it matter to have hv_vapic on at all?
>
> On Thu, Dec 4, 2014 at 9:24 AM, Zhang Haoyu wrote:
>>> Oh I see,
>>>
>>> So 101 BSOD problem is well know
>I just confirmed that vapic is causing win7 stuck.
>
You'd better try the commit fc57ac2c9ca :-)
>On Thu, Dec 4, 2014 at 9:34 AM, Thomas Lau wrote:
>> Hi,
>>
>> I don't want to recompile stuff, does it matter to have hv_vapic on at all?
>>
>> On Thu, Dec 4, 2014 at 9:24 AM, Zhang Haoyu wrote:
>
Sure, but I am little confused as KVM is part of linux kernel now, if
I want to try it, should I just upgrade kernel or compile kvm kernel
module by myself ?!
On Thu, Dec 4, 2014 at 10:01 AM, Zhang Haoyu wrote:
>>I just confirmed that vapic is causing win7 stuck.
>>
> You'd better try the commit
>Sure, but I am little confused as KVM is part of linux kernel now, if
>I want to try it, should I just upgrade kernel or compile kvm kernel
>module by myself ?!
>
You can just apply the patch to kvm module and rebuild it.
>On Thu, Dec 4, 2014 at 10:01 AM, Zhang Haoyu wrote:
>>>I just confirmed t
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is the
implementation of Intel GVT-g technology, a full GPU virtualization solution.
Under Intel GVT-g, a virtual GPU instance is maintained for each VM, with part
of performance critical resources directly assigned.
what does vapic affect Windows 7 at all if I disable it? if it just a
minor performance drop, I am fine with that.
On Thu, Dec 4, 2014 at 10:06 AM, Zhang Haoyu wrote:
>>Sure, but I am little confused as KVM is part of linux kernel now, if
>>I want to try it, should I just upgrade kernel or compil
>what does vapic affect Windows 7 at all if I disable it? if it just a
>minor performance drop, I am fine with that.
>
hv_vapic provides accelerated MSR access to high usage memory mapped APIC
registers, EOI, ICR, TPR.
You can gain performance promotion from it, not too much,
but it also depends on
Currently the calculations of stolen time for PPC Book3S HV guests
uses fields in both the vcpu struct and the kvmppc_vcore struct. The
fields in the kvmppc_vcore struct are protected by the
vcpu->arch.tbacct_lock of the vcpu that has taken responsibility for
running the virtual core. This works
I see, so it's minor performance gain, and not stability related
option which is good.
I am checking http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.5-trusty/,
changelog showing lsr function is included, but when I download and
extract kvm.ko out then run nm kvm.ko | grep lsr, nothing found
Is this the correct function?
kvm_lapic_set_eoi
I found that one tho.
On Thu, Dec 4, 2014 at 2:22 PM, Thomas Lau wrote:
> I see, so it's minor performance gain, and not stability related
> option which is good.
>
> I am checking
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.5-trusty/
>Is this the correct function?
>kvm_lapic_set_eoi
>
No, see the detail of commit fc57ac2c9ca,
https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/arch/x86/kvm/lapic.c?id=fc57ac2c9ca8109ea97fcc594f4be436944230cc
>I found that one tho.
>
>On Thu, Dec 4, 2014 at 2:22 PM, Thomas Lau wrote:
>> I see,
On 03/12/2014 23:56, Andy Lutomirski wrote:
> > This check is off by one. It is checking bits 63:47 instead of bits
> > 63:48 (this quirk is intentionally part of the specification, so that
> > you can reenter a guest at 0x8000 after e.g. a VMCALL vmexit and
> > cause a general protectio
92 matches
Mail list logo
