Re: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure

[Avi Kivity]

Dong, Eddie wrote:
> It is not a small change, I still need to study the whole patch :(
> If I can get some question clarified earlier, that helps a lot.
>
>
>   
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of 
>> Avi Kivity
>> Sent: 2007年12月4日 17:44
>> To: kvm-devel@lists.sourceforge.net
>> Subject: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure
>>
>> The current irq and exception injection infrastructure is 
>> quite complex and
>> has been the source of a number of bugs in the past.  This 
>> patchset simplifies
>> irq and exception injection:
>>
>> - Much more work is carried out in common code rather than 
>> vmx/svm specific
>>  code.  Information is kept in C variables rather than 
>> hardware registers
>>
>> - Exception and interrupts are separated into two independent 
>> queues.  This
>>  will allow later optimization on AMD where the hardware 
>> supports two queues,
>>  and also simplifies the Intel case as now we don't need to 
>> check the hardware
>>  whether an exception is pending when injecting and interrupt.
>>
>> - Interrupts are now only acked after they have been 
>> successfully injected,
>> 
>
> Mmm, how can you know if it is injected successfully?
> From the patch, it looks like you know this by checking
> IDT_Vectoring in next VM Exit. That means the virtual 
> interrupt controller state in memory is incorrect temply.
>
> If the injection success & we can get VM Exit before 
> next access to those virtual interrupt controller state,
> that will be OK, 

That's the idea.

> but that means we eliminate future HW
> optimization opportunity.  I think we just pay too much
> for coding style reason to narrow HW optimization space.
>   

I don't know enough about future hardware...

But the motivation here is not coding style, it's to be able to do the
injection non-atomically. The tpr-opt patchset wants to write the tpr to
memory, and that is a sleeping operation. Similarly, if we emulate big
real mode we need to simulate interrupt injection by writing to the stack.

Moving the logic to common code helps, but it could have been done with
the original system as well.

> If the injection fails, the previous logic will inject it back 
> immediately; current logic will do normal irq inject path.
> The potential differences are:
>   1: If a new higher interrupt arrives, we inject new vector.
> that is probably OK.
>   2: If the fault VM Exit is due to nested exception, the
> previous logic will probably inject double fault with the original
> interrupt consumed (acked); the new logic will probably inject
> double fault too, but keep the IRQ not consumed. I don't have
> direct case, but worry about those kind of deviation from native
> behavor.
>   

We can probably fix it to ack the interrupt when injecting a double fault.

-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Avi Kivity]

Izik Eidus wrote:
>>>
>>> [Yunfeng] Yes, it may not be a recent regression, and it may be a platform 
>>> related issue.
>>> Before we used Harwitch /paxville to do the test, and in a period the 
>>> installation test could pass without any problem.
>>> But after we switched the test machine to Dempsey/Woodcrest, the 
>>> installation test always fails.
>>>
>>>   
>>> 
>>>   
>> It seems to be related to hardware tpr threshold support, but I'm not 
>> 100% certain.
>>   
>> 
> why do you think so?
> tests that i did showed that (at least one of the problems) is in other 
> place
>
>
>   

I disabled hardware tpr threshold, and it worked.


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure

[Dong, Eddie]

>>
>> Mmm, how can you know if it is injected successfully?
>> From the patch, it looks like you know this by checking
>> IDT_Vectoring in next VM Exit. That means the virtual 
>> interrupt controller state in memory is incorrect temply.
>>
>> If the injection success & we can get VM Exit before 
>> next access to those virtual interrupt controller state,
>> that will be OK, 
>
>That's the idea.
>
>> but that means we eliminate future HW
>> optimization opportunity.  I think we just pay too much
>> for coding style reason to narrow HW optimization space.
>>   
>
>I don't know enough about future hardware...

One of the optimization, which can be used in pure SW is that
we can shadow APIC state as "RO" to guest so that all guest
read to APIC registers can run in full speed. T

This optimization is probably cleaner & less-intrusive. Dynamic
patching to modify guest code could trigger mine sooner or later:(


>
>But the motivation here is not coding style, it's to be able to do the
>injection non-atomically. The tpr-opt patchset wants to write 
>the tpr to
>memory, and that is a sleeping operation. Similarly, if we emulate big
>real mode we need to simulate interrupt injection by writing 
>to the stack.

OK. For  big real mode has issue, that is very easy
 to walk around, we can probably pre-load (pin) those 2 or 3 pages
before 
injecting real mode irq.

For dynamic patch stuff, what is the issue? I saw your previous code
works, right?

BTW, w/o this patch, your previous TPR optimization patch can work,
w/ this patch, it won't work. The key difference is when guest access
TPR,
per original patch, it will dynamically calcuate the vPPR value base on
vISR & vTPR. Since vISR is incorrect now (though temply), the patch
won't work correctly.

>
>Moving the logic to common code helps, but it could have been done with
>the original system as well.

Yes, probably we can split this 2 efforts. The part to make it common
can be 
easily in first.

>
>> If the injection fails, the previous logic will inject it back 
>> immediately; current logic will do normal irq inject path.
>> The potential differences are:
>>  1: If a new higher interrupt arrives, we inject new vector.
>> that is probably OK.
>>  2: If the fault VM Exit is due to nested exception, the
>> previous logic will probably inject double fault with the original
>> interrupt consumed (acked); the new logic will probably inject
>> double fault too, but keep the IRQ not consumed. I don't have
>> direct case, but worry about those kind of deviation from native
>> behavor.
>>   
>
>We can probably fix it to ack the interrupt when injecting a 
>double fault.

Yes, could be though not very clean. But I am not sure how many 
other reason will cause interrupt injection failed beside shadow fault.
We need to check all of them.

Eddie

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure

[Avi Kivity]

Dong, Eddie wrote:
>>> Mmm, how can you know if it is injected successfully?
>>> From the patch, it looks like you know this by checking
>>> IDT_Vectoring in next VM Exit. That means the virtual 
>>> interrupt controller state in memory is incorrect temply.
>>>
>>> If the injection success & we can get VM Exit before 
>>> next access to those virtual interrupt controller state,
>>> that will be OK, 
>>>   
>> That's the idea.
>>
>> 
>>> but that means we eliminate future HW
>>> optimization opportunity.  I think we just pay too much
>>> for coding style reason to narrow HW optimization space.
>>>   
>>>   
>> I don't know enough about future hardware...
>> 
>
> One of the optimization, which can be used in pure SW is that
> we can shadow APIC state as "RO" to guest so that all guest
> read to APIC registers can run in full speed. T
>
>   

This can still be done with unacked interrupts: modify the state to "as 
if" the interrupt was injected, but commit it only if the injection 
succeeds.  If injection fails, revert the change.  It isn't very nice 
though.

Another possibility is:

   get_interrupt()
... do all sleepy things prior to injection
enter critical section
ack interrupt
enter guest

> This optimization is probably cleaner & less-intrusive. Dynamic
> patching to modify guest code could trigger mine sooner or later:(
>
>   

Dynamic patching is dangerous, but the only option to run Windows SMP on 
millions of machines out there.

>   
>> But the motivation here is not coding style, it's to be able to do the
>> injection non-atomically. The tpr-opt patchset wants to write 
>> the tpr to
>> memory, and that is a sleeping operation. Similarly, if we emulate big
>> real mode we need to simulate interrupt injection by writing 
>> to the stack.
>> 
>
> OK. For  big real mode has issue, that is very easy
>  to walk around, we can probably pre-load (pin) those 2 or 3 pages
> before 
> injecting real mode irq.
>   

Pinning has problems of its own.  It can be made to work though.  In any 
case, it can fail, so we need to ack the interrupt only after we have 
successfully pinned the page.

> For dynamic patch stuff, what is the issue? I saw your previous code
> works, right?
>
> BTW, w/o this patch, your previous TPR optimization patch can work,
> w/ this patch, it won't work. The key difference is when guest access
> TPR,
> per original patch, it will dynamically calcuate the vPPR value base on
> vISR & vTPR. Since vISR is incorrect now (though temply), the patch
> won't work correctly.
>
>   

Sure, it needs to be adjusted.

>> Moving the logic to common code helps, but it could have been done with
>> the original system as well.
>> 
>
> Yes, probably we can split this 2 efforts. The part to make it common
> can be 
> easily in first.
>
>   
>>> If the injection fails, the previous logic will inject it back 
>>> immediately; current logic will do normal irq inject path.
>>> The potential differences are:
>>> 1: If a new higher interrupt arrives, we inject new vector.
>>> that is probably OK.
>>> 2: If the fault VM Exit is due to nested exception, the
>>> previous logic will probably inject double fault with the original
>>> interrupt consumed (acked); the new logic will probably inject
>>> double fault too, but keep the IRQ not consumed. I don't have
>>> direct case, but worry about those kind of deviation from native
>>> behavor.
>>>   
>>>   
>> We can probably fix it to ack the interrupt when injecting a 
>> double fault.
>> 
>
> Yes, could be though not very clean. But I am not sure how many 
> other reason will cause interrupt injection failed beside shadow fault.
> We need to check all of them.
>   

Injection can fail (or rather, not happen at all) if we do sleepy 
operations and then get a signal.  In that case, it is better to leave 
the interrupt unacked.

What do you think about the first six patches?  I think we can merge 
them now, and continue discussion about the last, which actually splits 
the injection.  I'll think further about acking the interrupt before 
entry, but after possibly sleepy operations have been done.

-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure

[Dong, Eddie]

 
>>
>> One of the optimization, which can be used in pure SW is that
>> we can shadow APIC state as "RO" to guest so that all guest
>> read to APIC registers can run in full speed. T
>>
>>   
>
>This can still be done with unacked interrupts: modify the 
>state to "as 
>if" the interrupt was injected, but commit it only if the injection 
>succeeds.  If injection fails, revert the change.  It isn't very nice 
>though.

Agree.

>
>Another possibility is:
>
>   get_interrupt()
>... do all sleepy things prior to injection
>enter critical section
>ack interrupt
>enter guest
>

Yes, that is safe and similar with current logic. Plus one condition:
if (real mode) for those sleepy things.

>> This optimization is probably cleaner & less-intrusive. Dynamic
>> patching to modify guest code could trigger mine sooner or later:(
>>
>>   
>
>Dynamic patching is dangerous, but the only option to run 
>Windows SMP on 
>millions of machines out there.

I know:)
RO of APIC page can solve this issue in most case.

>
>>   
>>> But the motivation here is not coding style, it's to be 
>able to do the
>>> injection non-atomically. The tpr-opt patchset wants to write 
>>> the tpr to
>>> memory, and that is a sleeping operation. Similarly, if we 
>emulate big
>>> real mode we need to simulate interrupt injection by writing 
>>> to the stack.
>>> 
>>
>> OK. For  big real mode has issue, that is very easy
>>  to walk around, we can probably pre-load (pin) those 2 or 3 pages
>> before 
>> injecting real mode irq.
>>   
>
>Pinning has problems of its own.  It can be made to work 
>though.  In any 
>case, it can fail, so we need to ack the interrupt only after we have 
>successfully pinned the page.

What I mean is we pre-load 2 pages where the stack are in, the logic may
be:

If (real mode)
get 2 pages.
enter critical path

VM Resume.
put these 2 pages.
handle VM Exit normally.


Since real mode is just a boot/install time isseu, performance is not
critical. This way doesn't hurt us.


thx,eddie

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] QEMU/KVM reboot after loading from statefile

[Uri Lublin]

Lukasz Lempart wrote:
> Hi,
>
> I am having a problem with starting qemu/kvm from a previously saved 
> statefile. qemu/kvm starts and the console output is the same as when 
> I initially stopped the vm and saved state. However, after a 'cont' 
> the guest reboots (i.e. takes me back to the grub menu).
>
> The specs for my setup are as follows:
>
> kvm version: 55 (same issue with 52, and when attempted with 44 
> instead of going back to the grub screen the vm would just freeze)
>
> Is this a known bug, or am I doing somethign wrong (i.e. using an 
> incompatible kernel version)?
> Any help would be greatly appreciated as I am attempting to get this 
> working for a school project. Please e-mail me at [EMAIL PROTECTED] 
>  with any suggestions/solutions to the 
> problem (I am not currently a member of the mailing list).
>
> Thank you in advance for all your help.
>
> Lukasz Lempart
It is a known bug.  Migration is currently broken. I'm working on it.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Izik Eidus]

Avi Kivity wrote:
> Izik Eidus wrote:

 [Yunfeng] Yes, it may not be a recent regression, and it may be a 
 platform related issue.
 Before we used Harwitch /paxville to do the test, and in a period 
 the installation test could pass without any problem.
 But after we switched the test machine to Dempsey/Woodcrest, the 
 installation test always fails.

 
>>> It seems to be related to hardware tpr threshold support, but I'm 
>>> not 100% certain.
>>>   
>> why do you think so?
>> tests that i did showed that (at least one of the problems) is in 
>> other place
>>
>>
>>   
>
> I disabled hardware tpr threshold, and it worked.
>
>
ok, please let me know when you are 100% sure it is,
i wasted alot of time for this bug

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Dong, Eddie]

 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of 
>Izik Eidus
>Sent: 2007年12月6日 19:27
>To: Avi Kivity
>Cc: kvm-devel
>Subject: Re: [kvm-devel] KVM Test result, kernel 51727a1.. 
>,userspace 6a385c9..
>
>Avi Kivity wrote:
>> Izik Eidus wrote:
>
> [Yunfeng] Yes, it may not be a recent regression, and it may be a 
> platform related issue.
> Before we used Harwitch /paxville to do the test, and in a period 
> the installation test could pass without any problem.
> But after we switched the test machine to Dempsey/Woodcrest, the 
> installation test always fails.
>
> 
 It seems to be related to hardware tpr threshold support, but I'm 
 not 100% certain.
   
>>> why do you think so?
>>> tests that i did showed that (at least one of the problems) is in 
>>> other place
>>>
>>>
>>>   
>>
>> I disabled hardware tpr threshold, and it worked.
>>
>>
>ok, please let me know when you are 100% sure it is,
>i wasted alot of time for this bug
>

How do u disable TPR? Remove the patch, or just remove the setting?

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure

[Dong, Eddie]

>
>What I mean is we pre-load 2 pages where the stack are in, the 
>logic may
>be:
>
>If (real mode)
>   get 2 pages.
>enter critical path
>
>VM Resume.
>put these 2 pages.
>handle VM Exit normally.
>
>
With 2nd thinking, We can cache these 2 pages. Something like:
if (real mode)
cache_2_pages (ss:esp)
enter critical path.

In cache_2_pages, old cache can be invalidated (put to user pages), new
pages are loaded (get user page) to avoid SW irq injection page fault.
When switch from real mode to protect mode, invalidate the page cache.

This just needs minimal change :)
Eddie

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Avi Kivity]

Dong, Eddie wrote:
> How do u disable TPR? Remove the patch, or just remove the setting?
>   

Just put 'return 0' in cpu_has_tpr_shadow() (or however it is called).


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Izik Eidus]

Avi Kivity wrote:
> Dong, Eddie wrote:
>   
>> How do u disable TPR? Remove the patch, or just remove the setting?
>>   
>> 
>
> Just put 'return 0' in cpu_has_tpr_shadow() (or however it is called).
>
>
>   
avi, can you please ask from alexeye to test it with this fix?
(some times i had booted 5 times guests without it crushed after heavy
load but then it did crushed at the 6 time),
to me it look that the only stable version for vista 64 was in the
middle from kvm-35 to kvm-36 (at commit
253abdee5ec2edd0a7f6dc2358bef42e3fdf1f39)...

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH 0/7] Rework irq injection infrastructure

[Avi Kivity]

Dong, Eddie wrote:
>> What I mean is we pre-load 2 pages where the stack are in, the 
>> logic may
>> be:
>>
>> If (real mode)
>>  get 2 pages.
>> enter critical path
>> 
>> VM Resume.
>> put these 2 pages.
>> handle VM Exit normally.
>>
>>
>> 
> With 2nd thinking, We can cache these 2 pages. Something like:
> if (real mode)
>   cache_2_pages (ss:esp)
> enter critical path.
>
> In cache_2_pages, old cache can be invalidated (put to user pages), new
> pages are loaded (get user page) to avoid SW irq injection page fault.
> When switch from real mode to protect mode, invalidate the page cache.
>
>   

I prefer the first one.  Indefinitely holding on to pages is not good, 
we may want to remove those pages for swapping or page migration.


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] virtnet: remove double ether_setup

[Christian Borntraeger]

Hello Rusty,

virtnet_probe already calls alloc_etherdev, which calls ether_setup.
There is no need to do that again.

Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
 drivers/net/virtio_net.c |1 -
 1 file changed, 1 deletion(-)

Index: kvm/drivers/net/virtio_net.c
===
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -329,11 +329,10 @@ static int virtnet_probe(struct virtio_d
dev = alloc_etherdev(sizeof(struct virtnet_info));
if (!dev)
return -ENOMEM;
 
/* Set up network device as normal. */
-   ether_setup(dev);
dev->open = virtnet_open;
dev->stop = virtnet_close;
dev->hard_start_xmit = start_xmit;
dev->features = NETIF_F_HIGHDMA;
SET_NETDEV_DEV(dev, &vdev->dev);

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] RFC: simplify kvm-userspace to qemu-kvm callback structure

[Avi Kivity]

Christian Ehrhardt wrote:
> Background:
> In our ppc code for the demo we only needed a call to 
> cpu_physical_memory_rw to handle all kind of mmio we needed. Looking 
> at all the callback pointers for read/write mmio in kvm_callbacks I 
> wondered if this can be simplified with cpu_physical_memory_rw for x86 
> too. So I tested it today and it works fine on with kvm-svm on my 
> opteron.
> The only code that did not just redirect to another function was a 
> workaround for a Redhat 7.1 issue, so I merged it in the central call 
> making it easier to find and maintain (was split before) anyway.
> If everyone agrees with it I will create a new patch also affecting 
> the other implementations of this interface e.g. user/main.c and a 
> rebased version of this one.
> But maybe there was a reason to do it that split way with all the 
> callback pointers that was not obvious to me, so please comment.

It may be worthwhile to unify all the reads into a single read, but read 
and write are fundamentally different.  The fact that qemu implements it 
in one function is a detail; libkvm aims to satisfy more than just qemu.


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] x86: emulate read/write access to cr8

[Joerg Roedel]

From: Joerg Roedel <[EMAIL PROTECTED]>

This patch adds code to emulate the access to the cr8 register to the x86
instruction emulator in kvm.

Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
---
 drivers/kvm/x86.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index 6deb052..9db4e32 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -2236,6 +2236,8 @@ unsigned long realmode_get_cr(struct kvm_vcpu *vcpu, int 
cr)
return vcpu->cr3;
case 4:
return vcpu->cr4;
+   case 8:
+   return get_cr8(vcpu);
default:
vcpu_printf(vcpu, "%s: unexpected cr %u\n", __FUNCTION__, cr);
return 0;
@@ -2259,6 +2261,9 @@ void realmode_set_cr(struct kvm_vcpu *vcpu, int cr, 
unsigned long val,
case 4:
set_cr4(vcpu, mk_cr_64(vcpu->cr4, val));
break;
+   case 8:
+   set_cr8(vcpu, val & 0xfUL);
+   break;
default:
vcpu_printf(vcpu, "%s: unexpected cr %u\n", __FUNCTION__, cr);
}
-- 
1.5.2.5




-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] Use cmpxchg for pte updates on walk_addr()

[Marcelo Tosatti]

In preparation for multi-threaded guest pte walking, use cmpxchg()
when updating guest pte's. This guarantees that the assignment of the
dirty bit can't be lost if two CPU's are faulting the same address
simultaneously.

In case of pte update via write emulation, no synchronization is
necessary since its the guest responsability.

Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>


diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
index b24bc7c..593073a 100644
--- a/drivers/kvm/paging_tmpl.h
+++ b/drivers/kvm/paging_tmpl.h
@@ -78,6 +78,23 @@ static gfn_t gpte_to_gfn_pde(pt_element_t gpte)
return (gpte & PT_DIR_BASE_ADDR_MASK) >> PAGE_SHIFT;
 }
 
+static inline void FNAME(kvm_cmpxchg_guest_pte)(struct kvm *kvm,
+gfn_t table_gfn, unsigned index, pt_element_t new_bits)
+{
+   pt_element_t pte;
+   pt_element_t *table;
+   struct page *page;
+
+   page = gfn_to_page(kvm, table_gfn);
+   table = kmap_atomic(page, KM_USER0);
+
+   do {
+   pte = table[index];
+   } while (cmpxchg(&table[index], pte, pte | new_bits) != pte);
+
+   kunmap_atomic(page, KM_USER0);
+}
+
 /*
  * Fetch a guest pte for a guest virtual address
  */
@@ -136,7 +153,8 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
if (!(pte & PT_ACCESSED_MASK)) {
mark_page_dirty(vcpu->kvm, table_gfn);
pte |= PT_ACCESSED_MASK;
-   kvm_write_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte));
+   FNAME(kvm_cmpxchg_guest_pte)
+   (vcpu->kvm, table_gfn, index, pte);
}
 
if (walker->level == PT_PAGE_TABLE_LEVEL) {
@@ -161,7 +179,7 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
if (write_fault && !is_dirty_pte(pte)) {
mark_page_dirty(vcpu->kvm, table_gfn);
pte |= PT_DIRTY_MASK;
-   kvm_write_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte));
+   FNAME(kvm_cmpxchg_guest_pte)(vcpu->kvm, table_gfn, index, pte);
kvm_mmu_pte_write(vcpu, pte_gpa, (u8 *)&pte, sizeof(pte));
}
 
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index c70ac33..edba8ce 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -1510,6 +1510,9 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu, 
gpa_t gpa,
 {
int ret;
 
+   /* No need for kvm_cmpxchg_guest_pte here, its the guest 
+* responsability to synchronize pte updates and page faults.
+*/
ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
if (ret < 0)
return 0;

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] QEMU/KVM reboot after loading from statefile

[Lukasz Lempart]

On Dec 6, 2007 5:13 AM, Uri Lublin <[EMAIL PROTECTED]> wrote:

> Lukasz Lempart wrote:
> > Hi,
> >
> > I am having a problem with starting qemu/kvm from a previously saved
> > statefile. qemu/kvm starts and the console output is the same as when
> > I initially stopped the vm and saved state. However, after a 'cont'
> > the guest reboots (i.e. takes me back to the grub menu).
> >
> > The specs for my setup are as follows:
> >
> > kvm version: 55 (same issue with 52, and when attempted with 44
> > instead of going back to the grub screen the vm would just freeze)
> >
> > Is this a known bug, or am I doing somethign wrong (i.e. using an
> > incompatible kernel version)?
> > Any help would be greatly appreciated as I am attempting to get this
> > working for a school project. Please e-mail me at [EMAIL PROTECTED]
> >  with any suggestions/solutions to the
> > problem (I am not currently a member of the mailing list).
> >
> > Thank you in advance for all your help.
> >
> > Lukasz Lempart
> It is a known bug.  Migration is currently broken. I'm working on it.
>

Thank you very much.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Use cmpxchg for pte updates on walk_addr()

[Avi Kivity]

Marcelo Tosatti wrote:
> In preparation for multi-threaded guest pte walking, use cmpxchg()
> when updating guest pte's. This guarantees that the assignment of the
> dirty bit can't be lost if two CPU's are faulting the same address
> simultaneously.
>
> In case of pte update via write emulation, no synchronization is
> necessary since its the guest responsability.
>
> Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>
>
> diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
> index b24bc7c..593073a 100644
> --- a/drivers/kvm/paging_tmpl.h
> +++ b/drivers/kvm/paging_tmpl.h
> @@ -78,6 +78,23 @@ static gfn_t gpte_to_gfn_pde(pt_element_t gpte)
>   return (gpte & PT_DIR_BASE_ADDR_MASK) >> PAGE_SHIFT;
>  }
>  
> +static inline void FNAME(kvm_cmpxchg_guest_pte)(struct kvm *kvm,
> +  gfn_t table_gfn, unsigned index, pt_element_t new_bits)
>   

You can drop the kvm_ prefix since this is static.

> +{
> + pt_element_t pte;
> + pt_element_t *table;
> + struct page *page;
> +
> + page = gfn_to_page(kvm, table_gfn);
> + table = kmap_atomic(page, KM_USER0);
> +
> + do {
> + pte = table[index];
> + } while (cmpxchg(&table[index], pte, pte | new_bits) != pte);
> +
> + kunmap_atomic(page, KM_USER0);
> +}
>   

I don't think cmpxchg() handles 64-bits on i386; you need  cmpxchg64().

What happens if the guest changed the pte under our feet (say, one vcpu 
accesses the page, the other vcpu swaps it out, setting the pte to 
zero)?  We end up modifying the new pte.  So we need to compare against 
the original pte, and abort the walk if we fail to set the bit.

> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index c70ac33..edba8ce 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -1510,6 +1510,9 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu, 
> gpa_t gpa,
>  {
>   int ret;
>  
> + /* No need for kvm_cmpxchg_guest_pte here, its the guest 
> +  * responsability to synchronize pte updates and page faults.
> +  */
>   ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
>   if (ret < 0)
>   return 0;

Hmm.  What if an i386 pae guest carefully uses cmpxchg8b to atomically 
set a pte?  kvm_write_guest() doesn't guarantee atomicity, so an 
intended atomic write can be seen splitted by the guest walker doing a 
concurrent walk.

-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] x86: emulate read/write access to cr8

[Avi Kivity]

Joerg Roedel wrote:
> This patch adds code to emulate the access to the cr8 register to the x86
> instruction emulator in kvm.
>   

Applied, thanks.


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] China NXY _ Kyna---professional in compatible bulk ink, CISS, ink cartridge, toner cartridge, toner powder, photo paper etc_.eml

[kyna_zhou]

Dear Sir or Madam,

I got your name and address from Internet and knew you are in the business
of printer consumable products, which is within the scope of our business. 


We got factory in both ShenZhen and DongGuan in China, DongGuan facotry
cover 3500 square meters,and ShenZhen 2600 square meters. we have patent for
the main products--isobarically continuous ink supply system (CISS), patent
No. is ZL200420014615.1 .The ink from our company is fluent,stable,non-plug
up,real color.Because it made in non-dust workshop,and via 3 step filtrate. 

Should you have interest of items mentioned above? Kindly let us know by
return mail.

sincerely,
Miss Kyna Zhou
SHENZHEN NXY TECHNOLOGY CO.,LTD
Factory Add:2 / F, Block 3, Gong Keng Industrial zone, Shang mu gu, Pinghu
Town, Shenzhen City . China / 518111
Tel:+86-755-84501552
Fax:+86-755-84501679
http://eng.sznuoxin.com
[EMAIL PROTECTED]
MSN:[EMAIL PROTECTED], [EMAIL PROTECTED]
Skype: kynazhou

<>-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Avi Kivity]

Izik Eidus wrote:
> Avi Kivity wrote:
>   
>> Izik Eidus wrote:
>> 
> [Yunfeng] Yes, it may not be a recent regression, and it may be a 
> platform related issue.
> Before we used Harwitch /paxville to do the test, and in a period 
> the installation test could pass without any problem.
> But after we switched the test machine to Dempsey/Woodcrest, the 
> installation test always fails.
>
> 
>   
 It seems to be related to hardware tpr threshold support, but I'm 
 not 100% certain.
   
 
>>> why do you think so?
>>> tests that i did showed that (at least one of the problems) is in 
>>> other place
>>>
>>>
>>>   
>>>   
>> I disabled hardware tpr threshold, and it worked.
>>
>>
>> 
> ok, please let me know when you are 100% sure it is,
> i wasted alot of time for this bug
>
>   

I just fixed an x86 emulator problem which makes Vista x64 much happier, 
so it wasn't the only problem.


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] KVM Test result, kernel 51727a1.. , userspace 6a385c9..

[Izik Eidus]

Avi Kivity wrote:
> Izik Eidus wrote:
>> Avi Kivity wrote:
>>  
>>> Izik Eidus wrote:
>>>
>> [Yunfeng] Yes, it may not be a recent regression, and it may be a 
>> platform related issue.
>> Before we used Harwitch /paxville to do the test, and in a period 
>> the installation test could pass without any problem.
>> But after we switched the test machine to Dempsey/Woodcrest, the 
>> installation test always fails.
>>
>>   
> It seems to be related to hardware tpr threshold support, but I'm 
> not 100% certain.
>   
 why do you think so?
 tests that i did showed that (at least one of the problems) is in 
 other place


 
>>> I disabled hardware tpr threshold, and it worked.
>>>
>>>
>>> 
>> ok, please let me know when you are 100% sure it is,
>> i wasted alot of time for this bug
>>
>>   
>
> I just fixed an x86 emulator problem which makes Vista x64 much 
> happier, so it wasn't the only problem.
>
>
wow,
it good that you solved it, beacuse looking at the fix i see that i 
could have spent on this another year and not find it

-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] x86: emulate read/write access to cr8

[Avi Kivity]

Joerg Roedel wrote:
> From: Joerg Roedel <[EMAIL PROTECTED]>
>
> This patch adds code to emulate the access to the cr8 register to the x86
> instruction emulator in kvm.
>
>   

I wrote a unit test for 'mov cr8', and it passes!

Seems we aren't trapping cr8 access at all for svm.

-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] x86: emulate read/write access to cr8

[Avi Kivity]

Avi Kivity wrote:
> Joerg Roedel wrote:
>   
>> From: Joerg Roedel <[EMAIL PROTECTED]>
>>
>> This patch adds code to emulate the access to the cr8 register to the x86
>> instruction emulator in kvm.
>>
>>   
>> 
>
> I wrote a unit test for 'mov cr8', and it passes!
>
> Seems we aren't trapping cr8 access at all for svm.
>
>   

Okay, I added mov cr8 trapping to svm.c.


-- 
error compiling committee.c: too many arguments to function


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] performance specs on VT-x vmenter/exit

[Dan]

Greetings Honorable KVM Devs!

I am doing research on the performance characteristics of the Intel VMX
instructions, specifically with respect to KVM. I need to count the cycles
for a VMENTER and VMEXIT instruction under various conditions. (But getting
it to work at all would be cool :)

So the idea is to drop the cycle count in a register from the VMM, force a
VMENTER, drop the count in a different register, and force a VMEXIT. Then
get a last count and do appropriate adding/subtracting.
I'm working with a 2.6.22.6 vanilla kernel on an Core2Duo with KVM-54.

Questions:
 Is there a better way to get these numbers?
 If not, where in the KVM source should I aim to put these instructions
(file/line number/general area)?
 Any tips on forcing a vmexit out of the guest immediately after the count?

Thank you so much for your time.
  :dan
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance specs on VT-x vmenter/exit

[Anthony Liguori]

Avi Kivity wrote:
> Dan wrote:
>   
>> Greetings Honorable KVM Devs!
>>
>> I am doing research on the performance characteristics of the Intel
>> VMX instructions, specifically with respect to KVM. I need to count
>> the cycles for a VMENTER and VMEXIT instruction under various
>> conditions. (But getting it to work at all would be cool :)
>>
>> So the idea is to drop the cycle count in a register from the VMM,
>> force a VMENTER, drop the count in a different register, and force a
>> VMEXIT. Then get a last count and do appropriate adding/subtracting.
>> I'm working with a 2.6.22.6  vanilla kernel on an
>> Core2Duo with KVM-54.
>>
>> Questions:
>>  Is there a better way to get these numbers?
>>  If not, where in the KVM source should I aim to put these
>> instructions (file/line number/general area)?
>>  Any tips on forcing a vmexit out of the guest immediately after the
>> count?
>>
>> Thank you so much for your time.
>>   :dan
>> 
>
>
> Have a look at user/test/x86/vmexit.c, which does exactly that.
>
>   

That only gives you the combined count of a vmenter and vmexit.  If you 
want to measure the individual counts of a vmenter and a vmexit, the 
easiest thing to do is make sure the tsc_offset is always zero, and has 
the host and guest cooperate.  The host stashes away the tsc before 
entering the guest, the guest immediately would take the tsc and stash 
it in a register and then immediately enter generate an exit.  The host 
would then immediately take the tsc and stash it away.  You now have 
three readings and can use them to identify the cost of vmenter and vmexit.

Regards,

Anthony Liguori



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance specs on VT-x vmenter/exit

[Avi Kivity]

Dan wrote:
> Greetings Honorable KVM Devs!
>
> I am doing research on the performance characteristics of the Intel
> VMX instructions, specifically with respect to KVM. I need to count
> the cycles for a VMENTER and VMEXIT instruction under various
> conditions. (But getting it to work at all would be cool :)
>
> So the idea is to drop the cycle count in a register from the VMM,
> force a VMENTER, drop the count in a different register, and force a
> VMEXIT. Then get a last count and do appropriate adding/subtracting.
> I'm working with a 2.6.22.6  vanilla kernel on an
> Core2Duo with KVM-54.
>
> Questions:
>  Is there a better way to get these numbers?
>  If not, where in the KVM source should I aim to put these
> instructions (file/line number/general area)?
>  Any tips on forcing a vmexit out of the guest immediately after the
> count?
>
> Thank you so much for your time.
>   :dan


Have a look at user/test/x86/vmexit.c, which does exactly that.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance specs on VT-x vmenter/exit

[Avi Kivity]

Anthony Liguori wrote:
>>
>>
>> Have a look at user/test/x86/vmexit.c, which does exactly that.
>>
>>   
>
> That only gives you the combined count of a vmenter and vmexit.

Right; furthermore it measures kvm overhead and not just instruction 
latency.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] x86: emulate read/write access to cr8

[Joerg Roedel]

On Thu, Dec 06, 2007 at 07:51:49PM +0200, Avi Kivity wrote:
> Avi Kivity wrote:
> >Joerg Roedel wrote:
> >  
> >>From: Joerg Roedel <[EMAIL PROTECTED]>
> >>
> >>This patch adds code to emulate the access to the cr8 register to the x86
> >>instruction emulator in kvm.
> >>
> >>  
> >
> >I wrote a unit test for 'mov cr8', and it passes!
> >
> >Seems we aren't trapping cr8 access at all for svm.
> >
> >  
> 
> Okay, I added mov cr8 trapping to svm.c.

I have cr8 access intercepted here, but this is not sufficient for
getting Vista 64bit running. Therefore I have not sent the patch yet.

-- 
   |   AMD Saxony Limited Liability Company & Co. KG
 Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System|  Register Court Dresden: HRA 4896
 Research  |  General Partner authorized to represent:
 Center| AMD Saxony LLC (Wilmington, Delaware, US)
   | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy



-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Move CONFIG_X86 decleration to be x86 specificin configure script

[Jerone Young]

 On Thu, 2007-12-06 at 11:06 +0800, Zhang, Xiantao wrote:
> Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <[EMAIL PROTECTED]>
> > # Date 1196891226 21600
> > # Node ID a30e578bd6e2cf7599ce0c57066880658ddf2886
> > # Parent  b4cf8e05d20b3f4ca658bb4fdf3db3e4393a5d8a
> > Move CONFIG_X86 decleration to be x86 specific in configure script
> > 
> > In the configure script CONFIG_X86 is explicitly declared for
> > qemu. Now while today the support for other archs is not exactly
> > in kvm just yet (it's coming)..this shouldn't be specified for
> > everyone ;-)
> > 
> > Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> > 
> > diff --git a/configure b/configure
> > --- a/configure
> > +++ b/configure
> > @@ -99,6 +99,7 @@ fi
> >  #set parameters compiling
> >  if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
> >  target_exec="x86_64-softmmu"
> > +qemu_cflags+=" -DCONFIG_X86"
> 
> Hi, Young 
>   Are you sure it works for you? Seems in script, it can't
> recognize "+=".  Anyway, I also have a fix about it in my patch queue,
> when  I do ia64 porting.  

Really? Hmmm.. that is valid bash syntax.  Seems to work fine when I do
it on the command line. Also seems to work out in my script as well. If
this is the case then maybe it's a newer bash feature.

> Thanks
> Xiantao
> 
> 
> >
> 
> -
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > from Novell.  From the desktop to the data center, Linux is going
> > mainstream.  Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > ___
> > kvm-devel mailing list
> > kvm-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/kvm-devel
> 
> -
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> ___ kvm-devel mailing list 
> kvm-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Move CONFIG_X86 decleration to be x86 specificin configure script

[Avi Kivity]

Jerone Young wrote:
>> Hi, Young 
>>  Are you sure it works for you? Seems in script, it can't
>> recognize "+=".  Anyway, I also have a fix about it in my patch queue,
>> when  I do ia64 porting.  
>> 
>
> Really? Hmmm.. that is valid bash syntax.  Seems to work fine when I do
> it on the command line. Also seems to work out in my script as well. If
> this is the case then maybe it's a newer bash feature.
>   

Not all systems use bash.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

[kvm-devel] [PATCH] svm: exit to userspace if write to cr8 and not using in-kernel apic

[Joerg Roedel]

With this patch KVM on SVM will exit to userspace if the guest writes to CR8
and the in-kernel APIC is disabled.

Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
---
 drivers/kvm/svm.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 677b525..9f8564a 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1048,6 +1048,15 @@ static int emulate_on_interception(struct vcpu_svm *svm,
return 1;
 }
 
+static int cr8_write_interception(struct vcpu_svm *svm, struct kvm_run 
*kvm_run)
+{
+   emulate_instruction(&svm->vcpu, NULL, 0, 0, 0);
+   if (irqchip_in_kernel(svm->vcpu.kvm))
+   return 1;
+   kvm_run->exit_reason = KVM_EXIT_SET_TPR;
+   return 0;
+}
+
 static int svm_get_msr(struct kvm_vcpu *vcpu, unsigned ecx, u64 *data)
 {
struct vcpu_svm *svm = to_svm(vcpu);
@@ -1202,7 +1211,7 @@ static int (*svm_exit_handlers[])(struct vcpu_svm *svm,
[SVM_EXIT_WRITE_CR0]= emulate_on_interception,
[SVM_EXIT_WRITE_CR3]= emulate_on_interception,
[SVM_EXIT_WRITE_CR4]= emulate_on_interception,
-   [SVM_EXIT_WRITE_CR8]= emulate_on_interception,
+   [SVM_EXIT_WRITE_CR8]= cr8_write_interception,
[SVM_EXIT_READ_DR0] = emulate_on_interception,
[SVM_EXIT_READ_DR1] = emulate_on_interception,
[SVM_EXIT_READ_DR2] = emulate_on_interception,
-- 
1.5.2.5




-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance specs on VT-x vmenter/exit

[Anthony Liguori]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>>
>>> Have a look at user/test/x86/vmexit.c, which does exactly that.
>>>
>>>   
>>
>> That only gives you the combined count of a vmenter and vmexit.
>
> Right; furthermore it measures kvm overhead and not just instruction 
> latency.

True.  Also, I don't know what Dan is looking to measure, but the cost 
of vmexits will varying depending on the reason for exit.  vmexit.c uses 
cpuid() which I suspect is slower than vmexit or pio but faster than 
pf.  It would be interesting to measure the individual exit reasons.

Regards,

Anthony Liguori



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] performance specs on VT-x vmenter/exit

[Dan]

Thanks for the lightning-fast response, guys.

I'll play around with vmexit.c and let some of this sink in.
I was hoping to get a clean count of ticks/vm[enter/exit] without the kvm
latency, and I thought putting in into the code in the kvm code in the
kernel source would accomplish something like that.

Getting counts per exit reason would be really neat too.

Thanks again, I'm sure I'll come back with more precise questions later :D
  :dan



On Dec 6, 2007 2:56 PM, Anthony Liguori <[EMAIL PROTECTED]> wrote:

> Avi Kivity wrote:
> > Anthony Liguori wrote:
> >>>
> >>>
> >>> Have a look at user/test/x86/vmexit.c, which does exactly that.
> >>>
> >>>
> >>
> >> That only gives you the combined count of a vmenter and vmexit.
> >
> > Right; furthermore it measures kvm overhead and not just instruction
> > latency.
>
> True.  Also, I don't know what Dan is looking to measure, but the cost
> of vmexits will varying depending on the reason for exit.  vmexit.c uses
> cpuid() which I suspect is slower than vmexit or pio but faster than
> pf.  It would be interesting to measure the individual exit reasons.
>
> Regards,
>
> Anthony Liguori
>
>
>
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Move CONFIG_X86 decleration to be x86 specificin configure script

[Jerone Young]

 On Thu, 2007-12-06 at 21:30 +0200, Avi Kivity wrote:
> Jerone Young wrote:
> >> Hi, Young 
> >>Are you sure it works for you? Seems in script, it can't
> >> recognize "+=".  Anyway, I also have a fix about it in my patch queue,
> >> when  I do ia64 porting.  
> >> 
> >
> > Really? Hmmm.. that is valid bash syntax.  Seems to work fine when I do
> > it on the command line. Also seems to work out in my script as well. If
> > this is the case then maybe it's a newer bash feature.
> >   
> 
> Not all systems use bash.

True, but at the top of the configure script is "#!/bin/bash" :-)

perhaps an easier way is to just do 


qemu_cflags="$qemu_cflags --DCONFIG_X86"

This way there shouldn't be any issues.


Here is a patch:

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

Move CONFIG_X86 decleration to be x86 specific in configure script

In the configure script CONFIG_X86 is explicitly declared for
qemu. 

Signed-off-by: Jerone Young <[EMAIL PROTECTED]>

diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -99,6 +99,7 @@ fi
 #set parameters compiling
 if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
 target_exec="x86_64-softmmu"
+qemu_cflags="$qemu_cflags -DCONFIG_X86"
 fi
 
 if [ "$arch" = "ia64" ]; then
@@ -113,7 +114,7 @@ fi
 #configure qemu
 (cd qemu; ./configure --target-list=$target_exec \
 --disable-kqemu \
---extra-cflags="-I $PWD/../libkvm $qemu_cflags -DCONFIG_X86" \
+--extra-cflags="-I $PWD/../libkvm $qemu_cflags" \
 --extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
 --enable-kvm --kernel-path="$libkvm_kerneldir" \
 ${enable_alsa:+"--enable-alsa"} \



-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Move CONFIG_X86 decleration tobe x86 specificin configure script

[Zhang, Xiantao]

Jerone Young wrote:
>  On Thu, 2007-12-06 at 21:30 +0200, Avi Kivity wrote:
>> Jerone Young wrote:
 Hi, Young
Are you sure it works for you? Seems in script, it can't
 recognize "+=".  Anyway, I also have a fix about it in my patch
 queue, when  I do ia64 porting. 
 
>>> 
>>> Really? Hmmm.. that is valid bash syntax.  Seems to work fine when
>>> I do it on the command line. Also seems to work out in my script as
>>> well. If this is the case then maybe it's a newer bash feature.
>>> 
>> 
>> Not all systems use bash.
> 
> True, but at the top of the configure script is "#!/bin/bash" :-)
> 
> perhaps an easier way is to just do
> 
> 
> qemu_cflags="$qemu_cflags --DCONFIG_X86"
> 
> This way there shouldn't be any issues.
> 
> 
> Here is a patch:
> 
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> 
> Move CONFIG_X86 decleration to be x86 specific in configure script
> 
> In the configure script CONFIG_X86 is explicitly declared for
> qemu.
> 
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
> 
> diff --git a/configure b/configure
> --- a/configure
> +++ b/configure
> @@ -99,6 +99,7 @@ fi
>  #set parameters compiling
>  if [ "$arch" = "i386" -o "$arch" = "x86_64" ]; then
>  target_exec="x86_64-softmmu"
> +qemu_cflags="$qemu_cflags -DCONFIG_X86"
>  fi
> 
>  if [ "$arch" = "ia64" ]; then
> @@ -113,7 +114,7 @@ fi
>  #configure qemu
>  (cd qemu; ./configure --target-list=$target_exec \
>  --disable-kqemu \
> ---extra-cflags="-I $PWD/../libkvm $qemu_cflags -DCONFIG_X86" \
> +--extra-cflags="-I $PWD/../libkvm $qemu_cflags" \
>  --extra-ldflags="-L $PWD/../libkvm $qemu_ldflags" \
>  --enable-kvm --kernel-path="$libkvm_kerneldir" \
>  ${enable_alsa:+"--enable-alsa"} \

Yes, That is also what I did in my patch. Been attached in privious mail
:)

Xiantao 

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-devel] [PATCH] Use cmpxchg for pte updates on walk_addr()

[Marcelo Tosatti]

On Thu, Dec 06, 2007 at 05:24:08PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> > In preparation for multi-threaded guest pte walking, use cmpxchg()
> > when updating guest pte's. This guarantees that the assignment of the
> > dirty bit can't be lost if two CPU's are faulting the same address
> > simultaneously.
> >
> > In case of pte update via write emulation, no synchronization is
> > necessary since its the guest responsability.
> >
> > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
> >
> >
> > diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
> > index b24bc7c..593073a 100644
> > --- a/drivers/kvm/paging_tmpl.h
> > +++ b/drivers/kvm/paging_tmpl.h
> > @@ -78,6 +78,23 @@ static gfn_t gpte_to_gfn_pde(pt_element_t gpte)
> > return (gpte & PT_DIR_BASE_ADDR_MASK) >> PAGE_SHIFT;
> >  }
> >  
> > +static inline void FNAME(kvm_cmpxchg_guest_pte)(struct kvm *kvm,
> > +gfn_t table_gfn, unsigned index, pt_element_t new_bits)
> >   
> 
> You can drop the kvm_ prefix since this is static.
> 
> > +{
> > +   pt_element_t pte;
> > +   pt_element_t *table;
> > +   struct page *page;
> > +
> > +   page = gfn_to_page(kvm, table_gfn);
> > +   table = kmap_atomic(page, KM_USER0);
> > +
> > +   do {
> > +   pte = table[index];
> > +   } while (cmpxchg(&table[index], pte, pte | new_bits) != pte);
> > +
> > +   kunmap_atomic(page, KM_USER0);
> > +}
> >   
> 
> I don't think cmpxchg() handles 64-bits on i386; you need  cmpxchg64().
> 
> What happens if the guest changed the pte under our feet (say, one vcpu 
> accesses the page, the other vcpu swaps it out, setting the pte to 
> zero)?  We end up modifying the new pte.  So we need to compare against 
> the original pte, and abort the walk if we fail to set the bit.

Right, patch at end of the message restarts the process if the pte
changes under the walker. The goto is pretty ugly, but I fail to see any
elegant way of doing that. Ideas?

> > diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> > index c70ac33..edba8ce 100644
> > --- a/drivers/kvm/x86.c
> > +++ b/drivers/kvm/x86.c
> > @@ -1510,6 +1510,9 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu, 
> > gpa_t gpa,
> >  {
> > int ret;
> >  
> > +   /* No need for kvm_cmpxchg_guest_pte here, its the guest 
> > +* responsability to synchronize pte updates and page faults.
> > +*/
> > ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
> > if (ret < 0)
> > return 0;
> 
> Hmm.  What if an i386 pae guest carefully uses cmpxchg8b to atomically 
> set a pte?  kvm_write_guest() doesn't guarantee atomicity, so an 
> intended atomic write can be seen splitted by the guest walker doing a 
> concurrent walk.

True, an atomic write is needed... a separate patch for that seems more
appropriate.


diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
index b24bc7c..a39f8a6 100644
--- a/drivers/kvm/paging_tmpl.h
+++ b/drivers/kvm/paging_tmpl.h
@@ -34,7 +34,9 @@
#define PT_LEVEL_BITS PT64_LEVEL_BITS
#ifdef CONFIG_X86_64
#define PT_MAX_FULL_LEVELS 4
+   #define CMPXCHG cmpxchg
#else
+   #define CMPXCHG cmpxchg64
#define PT_MAX_FULL_LEVELS 2
#endif
 #elif PTTYPE == 32
@@ -48,6 +50,7 @@
#define PT_LEVEL_MASK(level) PT32_LEVEL_MASK(level)
#define PT_LEVEL_BITS PT32_LEVEL_BITS
#define PT_MAX_FULL_LEVELS 2
+   #define CMPXCHG cmpxchg
 #else
#error Invalid PTTYPE value
 #endif
@@ -78,6 +81,24 @@ static gfn_t gpte_to_gfn_pde(pt_element_t gpte)
return (gpte & PT_DIR_BASE_ADDR_MASK) >> PAGE_SHIFT;
 }
 
+static inline bool FNAME(cmpxchg_gpte)(struct kvm *kvm,
+gfn_t table_gfn, unsigned index, 
+pt_element_t orig_pte, pt_element_t new_pte)
+{
+   pt_element_t ret;
+   pt_element_t *table;
+   struct page *page;
+
+   page = gfn_to_page(kvm, table_gfn);
+   table = kmap_atomic(page, KM_USER0);
+   
+   ret = CMPXCHG(&table[index], orig_pte, new_pte);
+
+   kunmap_atomic(page, KM_USER0);
+
+   return (ret != orig_pte);
+}
+
 /*
  * Fetch a guest pte for a guest virtual address
  */
@@ -91,6 +112,7 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
gpa_t pte_gpa;
 
pgprintk("%s: addr %lx\n", __FUNCTION__, addr);
+walk:
walker->level = vcpu->mmu.root_level;
pte = vcpu->cr3;
 #if PTTYPE == 64
@@ -135,8 +157,9 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
 
if (!(pte & PT_ACCESSED_MASK)) {
mark_page_dirty(vcpu->kvm, table_gfn);
-   pte |= PT_ACCESSED_MASK;
-   kvm_write_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte));
+   if (FNAME(cmpxchg_gpte)(vcpu->kvm, table_gfn, 
+   index, pte, pte|PT_ACCESSED_MASK))
+   goto walk;
}
 
if (walker->l

Re: [kvm-devel] [PATCH] Use cmpxchg for pte updates on walk_addr()

[Avi Kivity]

Marcelo Tosatti wrote:
> Right, patch at end of the message restarts the process if the pte
> changes under the walker. The goto is pretty ugly, but I fail to see any
> elegant way of doing that. Ideas?
>
>   

goto is fine for that.  But there's a subtle livelock here: suppose vcpu 
0 is in guest mode with continuously updating a memory location.  vcpu 1 
is faulting with that memory location acting as a pte.  While we're in 
kernel mode, we aren't responding to signals like we should; so we need 
to abort the walk and let the guest retry; that way we go through the 
signal_pending() check.

However, this is an intrusive change, so let's start with the goto and 
drop it later in favor or an abort.

>>> @@ -1510,6 +1510,9 @@ static int emulator_write_phys(struct kvm_vcpu *vcpu, 
>>> gpa_t gpa,
>>>  {
>>> int ret;
>>>  
>>> +   /* No need for kvm_cmpxchg_guest_pte here, its the guest 
>>> +* responsability to synchronize pte updates and page faults.
>>> +*/
>>> ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
>>> if (ret < 0)
>>> return 0;
>>>   
>> Hmm.  What if an i386 pae guest carefully uses cmpxchg8b to atomically 
>> set a pte?  kvm_write_guest() doesn't guarantee atomicity, so an 
>> intended atomic write can be seen splitted by the guest walker doing a 
>> concurrent walk.
>> 
>
> True, an atomic write is needed... a separate patch for that seems more
> appropriate.
>
>
>   

Yes.

> +static inline bool FNAME(cmpxchg_gpte)(struct kvm *kvm,
> +  gfn_t table_gfn, unsigned index, 
> +  pt_element_t orig_pte, pt_element_t new_pte)
> +{
> + pt_element_t ret;
> + pt_element_t *table;
> + struct page *page;
> +
> + page = gfn_to_page(kvm, table_gfn);
> + table = kmap_atomic(page, KM_USER0);
> + 
> + ret = CMPXCHG(&table[index], orig_pte, new_pte);
> +
> + kunmap_atomic(page, KM_USER0);
> +
>   

Missing kvm_release_page_dirty() here.  May also move mark_page_dirty() 
here.

No need to force inlining.

> + return (ret != orig_pte);
> +}
> +
>  /*
>   * Fetch a guest pte for a guest virtual address
>   */
> @@ -91,6 +112,7 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
>   gpa_t pte_gpa;
>  
>   pgprintk("%s: addr %lx\n", __FUNCTION__, addr);
> +walk:
>   walker->level = vcpu->mmu.root_level;
>   pte = vcpu->cr3;
>  #if PTTYPE == 64
> @@ -135,8 +157,9 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
>  
>   if (!(pte & PT_ACCESSED_MASK)) {
>   mark_page_dirty(vcpu->kvm, table_gfn);
> - pte |= PT_ACCESSED_MASK;
> - kvm_write_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte));
> + if (FNAME(cmpxchg_gpte)(vcpu->kvm, table_gfn, 
> + index, pte, pte|PT_ACCESSED_MASK))
> + goto walk;
>   

We lose the accessed bit in the local variable pte here.  Not sure if it 
matters but let's play it safe.

>   }
>  
>   if (walker->level == PT_PAGE_TABLE_LEVEL) {
> @@ -159,9 +182,13 @@ static int FNAME(walk_addr)(struct guest_walker *walker,
>   }
>  
>   if (write_fault && !is_dirty_pte(pte)) {
> + bool ret;
>   mark_page_dirty(vcpu->kvm, table_gfn);
> - pte |= PT_DIRTY_MASK;
> - kvm_write_guest(vcpu->kvm, pte_gpa, &pte, sizeof(pte));
> + ret = FNAME(cmpxchg_gpte)(vcpu->kvm, table_gfn, index, pte,
> + pte|PT_DIRTY_MASK);
> + if (ret)
> + goto walk;
> + 

Again we lose a bit in pte.  That ends up in walker->pte and is quite 
important.




-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel