On Sun, Sep 19, 2010 at 06:03:31PM -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 06:12:14PM +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote:
> > > I'm confused. The "cpu_set x offline" doesn't appear to do anything
> > > for me. It does not d
On Sun, Sep 19, 2010 at 05:57:25PM -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 06:24:33PM +0200, Conrad Wood wrote:
> >
> > a script with my exact steps is below. Result is reproducible.
> >
> [...]
> > echo "Ejecting CPU #4"
> > echo "cpu_set 4 offline" | nc ${MONITORHOST} ${MONITORPO
On Thu, Jun 17, 2010, Gleb Natapov wrote about "Re: [PATCH 22/24] Correct
handling of idt vectoring info":
> On Sun, Jun 13, 2010 at 03:33:50PM +0300, Nadav Har'El wrote:
> > In the normal non-nested case, the idt_vectoring_info case is treated after
> > the exit. However, in the nested case a dec
On Sun, Sep 19, 2010 at 06:12:14PM +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote:
> > I'm confused. The "cpu_set x offline" doesn't appear to do anything
> > for me. It does not disable the cpu, nor does it inform the guest to
> > disable the cpu.
[..
On Sun, Sep 19, 2010 at 06:24:33PM +0200, Conrad Wood wrote:
>
> a script with my exact steps is below. Result is reproducible.
>
[...]
> echo "Ejecting CPU #4"
> echo "cpu_set 4 offline" | nc ${MONITORHOST} ${MONITORPORT} >/dev/null
>
> printInfo
>
> echo "Setting all available cpus to online.
>>> On 9/19/2010 at 01:02 PM, in message <20100919170231.ga12...@redhat.com>,
"Michael S. Tsirkin" wrote:
> I think I see the following (theoretical) race:
>
> During irqfd assign, we drop irqfds lock before we
> schedule inject work. Therefore, deassign running
> on another CPU could cause shut
On Sun, Sep 19, 2010 at 07:50:27PM +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 07:29:41PM +0200, Joerg Roedel wrote:
> > On Sun, Sep 19, 2010 at 06:41:27PM +0200, Gleb Natapov wrote:
> > > Nested SVM checks for external interrupt after injecting nested exception.
> > > In case there is ext
On Sun, Sep 19, 2010 at 07:29:41PM +0200, Joerg Roedel wrote:
> On Sun, Sep 19, 2010 at 06:41:27PM +0200, Gleb Natapov wrote:
> > Nested SVM checks for external interrupt after injecting nested exception.
> > In case there is external interrupt pending the code generates "external
> > interrupt exi
On Sun, Sep 19, 2010 at 06:41:27PM +0200, Gleb Natapov wrote:
> Nested SVM checks for external interrupt after injecting nested exception.
> In case there is external interrupt pending the code generates "external
> interrupt exit" and overwrites previous exit info. If previously injected
> excepti
I think I see the following (theoretical) race:
During irqfd assign, we drop irqfds lock before we
schedule inject work. Therefore, deassign running
on another CPU could cause shutdown and flush to run
before inject, causing user after free in inject.
A simple fix it to schedule inject under the
On 09/19/2010 06:38 PM, Steven Rostedt wrote:
On Sun, 2010-09-19 at 15:09 +0200, Avi Kivity wrote:
> Some time ago, the i8259 emulation code in kvm was changed to use
> raw_spinlock_t, as it was called in a preempt_disable() and
> local_irq_disable() context, which doesn't work with preemptib
The PIC code used to be called from preempt_disable() context, which
wasn't very good for PREEMPT_RT. That is no longer the case, so move
back from raw_spinlock_t to spinlock_t.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/i8259.c |6 +++---
arch/x86/kvm/irq.h |2 +-
arch/x86/kvm/x86.c
Nested SVM checks for external interrupt after injecting nested exception.
In case there is external interrupt pending the code generates "external
interrupt exit" and overwrites previous exit info. If previously injected
exception already generated exit it will be lost.
Signed-off-by: Gleb Natapo
On Sun, 2010-09-19 at 15:09 +0200, Avi Kivity wrote:
> Some time ago, the i8259 emulation code in kvm was changed to use
> raw_spinlock_t, as it was called in a preempt_disable() and
> local_irq_disable() context, which doesn't work with preemptible
> spinlocks used with CONFIG_PREEMPT_RT.
>
>
On machines without monitor/mwait we use an sti; hlt sequence to atomically
enable interrupts and put the cpu to sleep. The sequence uses the "interrupt
shadow" property of the sti instruction: interrupts are enabled only after
the instruction following sti has been executed. This means an interr
On Sun, 2010-09-19 at 12:04 -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote:
> > >
> > > > > However after step 7 the guest can turn the cpu online again by
> > > > > issuing
> > > > > ec
On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote:
> > >
> > > > > However after step 7 the guest can turn the cpu online again by
> > > > > issuing
> > >
On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote:
> >
> > > > However after step 7 the guest can turn the cpu online again by issuing
> > > > echo 1 >/sys/devices/.../cpuX/online
> > > There will be no /sys/devices/.../cpu
On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote:
>
> > > However after step 7 the guest can turn the cpu online again by issuing
> > > echo 1 >/sys/devices/.../cpuX/online
> > There will be no /sys/devices/.../cpuX/online in guest after step 7.
>
> Well then at least in my version th
> > However after step 7 the guest can turn the cpu online again by issuing
> > echo 1 >/sys/devices/.../cpuX/online
> There will be no /sys/devices/.../cpuX/online in guest after step 7.
Well then at least in my version there's a bug, because it still is
there and never goes away. (kvm 0.12.5)
On Sun, Sep 19, 2010 at 05:37:18PM +0200, Conrad Wood wrote:
>
> > > I need to know if a cpu is currently inserted or ejected.
> > >
> > The only way to do that currently is to track it in your management app.
>
> The Management App does know which one should be inserted or ejected.
> I see now
> > I need to know if a cpu is currently inserted or ejected.
> >
> The only way to do that currently is to track it in your management app.
The Management App does know which one should be inserted or ejected.
I see now way of enforcing it though.
This is what I had in mind: (simplified)
1. M
On 09/19/2010 02:34 PM, Avi Kivity wrote:
Our current real mode interrupt injection injects external interrupts as
software interrupts, which is somewhat hacky. This is problematic in big
real mode (can't use vmx there) and on via processors (a cpu bug prevents
this from working correctly).
Re
On Sun, Sep 19, 2010 at 05:20:38PM +0200, Avi Kivity wrote:
> On 09/19/2010 01:59 PM, Gleb Natapov wrote:
> >>
> >I fixed it several times in the past[0][1][3], but it keeps re-appearing :) I
> >hope current qemu-kvm head is OK.
> >
> >[0] 865aa3fec2b3d83c9b6edd452050a30ef6eaf3b8
> >[1] 8c7d4cb716
On 09/19/2010 01:59 PM, Gleb Natapov wrote:
>
I fixed it several times in the past[0][1][3], but it keeps re-appearing :) I
hope current qemu-kvm head is OK.
[0] 865aa3fec2b3d83c9b6edd452050a30ef6eaf3b8
[1] 8c7d4cb7163d1c97df4439e2e0edb5918abf106b
[2] d6d233543d543fcf34df6190bbce5daf38d870f5
On Sun, Sep 19, 2010 at 05:16:24PM +0200, Conrad Wood wrote:
> [..]
>
> > Lets establish some terminology to understand each other better:
> > Lets use CPU inserted/ejected to refer to cpu being available/not
> > available to a guest.
> > Lest use CPU online/offline to refer to cpu been used by a
[..]
> Lets establish some terminology to understand each other better:
> Lets use CPU inserted/ejected to refer to cpu being available/not
> available to a guest.
> Lest use CPU online/offline to refer to cpu been used by a guest OS.
>
> CPU hot-plug works like this:
> cpu is inserted (plugged
Just figured out that it makes a lot of sens to measure the latency of
stgi and clgi too in this test. Here is an updated one.
>From 350d33d155db8928f81cc801587787c84d6bc8c5 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Sun, 19 Sep 2010 15:34:37 +0200
Subject: [PATCH] svm: Add VMLOAD/VMSAVE a
On Sun, Sep 19, 2010 at 04:07:50PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 15:50 +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 09:46:21AM -0400, Kevin O'Connor wrote:
> > > On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote:
> > > > halted state is not the way to check
Override kvm_emulate_insn formatting to use a disassembler to format
the emulated instruction. If a disassembler (udis86) is not available,
fall back to showing the instruction bytes in hex.
Signed-off-by: Avi Kivity
---
Note 1: on top of 'master' with 'trace-cmd-kvm' cherry-picked on top.
Not
On Sun, Sep 19, 2010 at 04:07:50PM +0200, Conrad Wood wrote:
> 1) Thanks for clarifying "online" vs "halted" - that makes sense and is
> probably part of what confused me. I need to get the "online/offline"
> status of cpus, not if they are halted or not. I understand this is
> currently not possib
On Sun, 2010-09-19 at 15:50 +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 09:46:21AM -0400, Kevin O'Connor wrote:
> > On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote:
> > > halted state is not the way to check for whether cpu is online or
> > > offline. cpu may be online but exe
This patch adds a test to measure the latency of the VMLOAD
and VMSAVE instructions.
Signed-off-by: Joerg Roedel
---
x86/svm.c | 52
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/x86/svm.c b/x86/svm.c
index babd77d..26bf566
This patch adds a test to measure the latency of VMRUN and
VMEXIT.
Signed-off-by: Joerg Roedel
---
x86/svm.c | 81 +
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/x86/svm.c b/x86/svm.c
index dc3098f..babd77d 100644
-
Hi,
here are two patches for the svm unit-test framework that measure the
latency of the emulated vmrun, vmload, and vmsave instructions as well
as the latency of emulated vmexits.
On my Phenom II X6 1090T running in P0 it produces output like this:
Latency VMRUN : max: 140956 min: 6770 avg:
On Sun, Sep 19, 2010 at 09:46:21AM -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote:
> > halted state is not the way to check for whether cpu is online or
> > offline. cpu may be online but executing hlt instruction so
> > its state will be halted, but cp
On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote:
> halted state is not the way to check for whether cpu is online or
> offline. cpu may be online but executing hlt instruction so
> its state will be halted, but cpu itself is online. Actually with kvm
> today you are not able to check
On Sun, Sep 19, 2010 at 03:35:47PM +0200, Conrad Wood wrote:
>
> > > hm... that's the version I am using und it does not work here ;(
> > > the hotplug itself seems to work but they're reported as halted.
> > I told you this is cosmetic. They are working.
>
> I agree, the hotplug itself seems to
On Sun, 2010-09-19 at 09:38 -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote:
> > On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote:
> > > On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote:
> > > > Known problem in qemu. There was a patch f
On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote:
> > On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote:
> > > Known problem in qemu. There was a patch for this, but qemu maintainers
> > > think it is not good enough.
> > hm... that's the version I am using und it does not work here ;(
> > the hotplug itself seems to work but they're reported as halted.
> I told you this is cosmetic. They are working.
I agree, the hotplug itself seems to be working!
> >
> > Then it seems to be a local misconfiguration.
and
On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote:
> > On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote:
> > > On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote:
> > > > hm... after upgrading to seabios 0.6.1
On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote:
> On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote:
> > On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote:
> > > hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today)
> > > I get:
> [...]
> > > any idea
On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote:
> On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote:
> > hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today)
> > I get:
[...]
> > any ideas ?
> >
> Known problem in qemu. There was a patch for this, but qem
Some time ago, the i8259 emulation code in kvm was changed to use
raw_spinlock_t, as it was called in a preempt_disable() and
local_irq_disable() context, which doesn't work with preemptible
spinlocks used with CONFIG_PREEMPT_RT.
In Linux 2.6.37, the spinlock will no longer be taken in these
On Fri, Sep 17, 2010 at 03:33:07PM +0530, Krishna Kumar wrote:
> For 1 TCP netperf, I ran 7 iterations and summed it. Explanation
> for degradation for 1 stream case:
Could you document how exactly do you measure multistream bandwidth:
netperf flags, etc?
> 1. Without any tuning, BW falls -6.
From: Mohammed Gamal
This adds a wrapper function kvm_inject_realmode_interrupt() around the
emulator function emulate_int_real() to allow real mode interrupt injection.
[avi: initialize operand and address sizes before emulating interrupts]
[avi: initialize rip for real mode interrupt injection
If an interrupt is pending, we need to stop emulation so we
can inject it.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 2572153..1a5ecfd 100644
--- a/arch/x86/kvm/vm
From: Mohammed Gamal
Signed-off-by: Mohammed Gamal
Signed-off-by: Avi Kivity
---
arch/x86/include/asm/kvm_emulate.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index 5187dd8..b36c6b3 100644
From: Mohammed Gamal
Replace the inject-as-software-interrupt hack we currently have with
emulated injection.
Signed-off-by: Mohammed Gamal
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c | 65 ---
1 files changed, 6 insertions(+), 59 deletio
Our current real mode interrupt injection injects external interrupts as
software interrupts, which is somewhat hacky. This is problematic in big
real mode (can't use vmx there) and on via processors (a cpu bug prevents
this from working correctly).
Replace the current mechanism with emulation; w
On Sun, 2010-09-19 at 13:59 +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 01:51:29PM +0200, Conrad Wood wrote:
> > On Sun, 2010-09-19 at 13:39 +0200, Gleb Natapov wrote:
> > > On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote:
> > > > On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov
On Sun, Sep 19, 2010 at 01:51:29PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 13:39 +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote:
> > > On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote:
> > > > On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conra
On Sun, 2010-09-19 at 13:39 +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote:
> > On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote:
> > > On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote:
> > > > On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov
On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote:
> > On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote:
> > > On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote:
> > > [...]
> > > > > But... why does the command "info
On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote:
> > On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote:
> > [...]
> > > > But... why does the command "info cpus" in the monitor report all cpus
> > > > apart from CPU0 as (halte
On Sun, Sep 19, 2010 at 01:05:09PM +0200, Avi Kivity wrote:
> On 09/19/2010 12:55 PM, Michael S. Tsirkin wrote:
> >On Sun, Sep 19, 2010 at 12:56:12PM +0200, Avi Kivity wrote:
> >> On 09/19/2010 12:45 PM, Michael S. Tsirkin wrote:
> >> >On Fri, Sep 17, 2010 at 09:59:29AM +0200, Gleb Natapov wrot
On Sun, Sep 19, 2010 at 01:18:44PM +0200, Gleb Natapov wrote:
> On Sun, Sep 19, 2010 at 12:55:12PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Sep 19, 2010 at 12:56:12PM +0200, Avi Kivity wrote:
> > > On 09/19/2010 12:45 PM, Michael S. Tsirkin wrote:
> > > >On Fri, Sep 17, 2010 at 09:59:29AM +020
On Sun, Sep 19, 2010 at 12:55:12PM +0200, Michael S. Tsirkin wrote:
> On Sun, Sep 19, 2010 at 12:56:12PM +0200, Avi Kivity wrote:
> > On 09/19/2010 12:45 PM, Michael S. Tsirkin wrote:
> > >On Fri, Sep 17, 2010 at 09:59:29AM +0200, Gleb Natapov wrote:
> > >> > writing 0 to eventfd does nothing. T
On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote:
> [...]
> > > But... why does the command "info cpus" in the monitor report all cpus
> > > apart from CPU0 as (halted) ?
> > >
> > Because they are halted? Run multiple cpu hogs in
On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote:
[...]
> > But... why does the command "info cpus" in the monitor report all cpus
> > apart from CPU0 as (halted) ?
> >
> Because they are halted? Run multiple cpu hogs in the guest and see if
> cpus will still be halted as reported by monitor.
On 09/19/2010 12:55 PM, Michael S. Tsirkin wrote:
On Sun, Sep 19, 2010 at 12:56:12PM +0200, Avi Kivity wrote:
> On 09/19/2010 12:45 PM, Michael S. Tsirkin wrote:
> >On Fri, Sep 17, 2010 at 09:59:29AM +0200, Gleb Natapov wrote:
> >> > writing 0 to eventfd does nothing. The way to deassert
On Sun, Sep 19, 2010 at 12:56:12PM +0200, Avi Kivity wrote:
> On 09/19/2010 12:45 PM, Michael S. Tsirkin wrote:
> >On Fri, Sep 17, 2010 at 09:59:29AM +0200, Gleb Natapov wrote:
> >> > writing 0 to eventfd does nothing. The way to deassert irq
> >> That is implementation detail of current irqfd.
On 09/19/2010 12:45 PM, Michael S. Tsirkin wrote:
On Fri, Sep 17, 2010 at 09:59:29AM +0200, Gleb Natapov wrote:
> > writing 0 to eventfd does nothing. The way to deassert irq
> That is implementation detail of current irqfd. It was designed for MSI
> not level triggered interrupts.
Maybe we
On Fri, Sep 17, 2010 at 09:59:29AM +0200, Gleb Natapov wrote:
> > writing 0 to eventfd does nothing. The way to deassert irq
> That is implementation detail of current irqfd. It was designed for MSI
> not level triggered interrupts.
Maybe we should add a check that gsi is mapped to MSI (or unmappe
On Sun, Sep 19, 2010 at 12:41:37PM +0200, Conrad Wood wrote:
> On Sun, 2010-09-19 at 08:38 +0200, Gleb Natapov wrote:
> > On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote:
> > > On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote:
> > > > On Fri, Sep 17, 2010 at 11:39:36PM +0200, Con
On Sun, 2010-09-19 at 08:38 +0200, Gleb Natapov wrote:
> On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote:
> > On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote:
> > > On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote:
> > > > Hi everyone,
> > > >
> > > > I'm currently l
On 09/19/2010 11:28 AM, Avi Kivity wrote:
On 09/19/2010 11:25 AM, Avi Kivity wrote:
Let's assume that this is so (I'll check).
It's trivially so. If a completion causes an interrupt to be raised,
the vcpu's apic code is executed in the iothread context.
However, that's a bug even wit
On 09/14/2010 05:59 PM, Joerg Roedel wrote:
Hi Avi,
here is the second version of the new unit-tests for the KVM SVM
emulation. The changes to the previous version are really minor:
* Fixed coding-style
* Fixed comment in the code that builds the nested page table
* Ren
On 09/19/2010 11:25 AM, Avi Kivity wrote:
Let's assume that this is so (I'll check).
It's trivially so. If a completion causes an interrupt to be raised,
the vcpu's apic code is executed in the iothread context.
--
error compiling committee.c: too many arguments to function
--
To unsubs
On 09/17/2010 09:12 PM, Marcelo Tosatti wrote:
> This is now merged, with the change pointed out by Marcelo. Windows
> XP x64 fails installation without
>
> (vmx.c handle_cr())
> case 8: {
> u8 cr8_prev = kvm_get_cr8(vcpu);
> u8 cr8 = kvm_registe
71 matches
Mail list logo
