Xen devel - Apr 2007 - [PATCH] Clear VMCS if reusing after vcpu reset

Clear whole page when VMCS is reused due to cpu hotplug.
construct_vmcs doesn''t take care of all fields and some stale
content may make hardware unhappy.

Signed-off-by Kevin Tian <kevin.tian@intel.com>

Thanks,
Kevin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/4/07 07:09, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> Clear whole page when VMCS is reused due to cpu hotplug.
> construct_vmcs doesn''t take care of all fields and some stale
> content may make hardware unhappy.
> 
> Signed-off-by Kevin Tian <kevin.tian@intel.com>
Which hotplug would that be? I can''t see how vmx_create_vmcs() can be
called
more than once for any vcpu. It''s called during vcpu creation and
that''s it
afaics. The current check for v->arch.hvm_vmx.vmcs==NULL is therefore
redundant.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年4月30日 14:41
>On 30/4/07 07:09, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
>
>> Clear whole page when VMCS is reused due to cpu hotplug.
>> construct_vmcs doesn''t take care of all fields and some stale
>> content may make hardware unhappy.
>>
>> Signed-off-by Kevin Tian <kevin.tian@intel.com>
>
>Which hotplug would that be? I can''t see how vmx_create_vmcs() can
>be called
>more than once for any vcpu. It''s called during vcpu creation and
that''s it
>afaics. The current check for v->arch.hvm_vmx.vmcs==NULL is
>therefore
>redundant.
>
> -- Keir
Within HVM domain:
Echo "0" > /sys/devices/system/cpu/cpuN/online;
Echo "1" > /sys/devices/system/cpu/cpuN/online; 

Hvm_vcpu_reset is invoked as the result of receiving vINIT, which 
then goes to hvm_vcpu_initialise, vmx_vcpu_initialise, 
vmx_create_vmcs.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>Which hotplug would that be? I can''t see how vmx_create_vmcs()
can be
called
>>more than once for any vcpu. It''s called during vcpu creation
and
that''s it
>>afaics. The current check for v->arch.hvm_vmx.vmcs==NULL is therefore
>>redundant.
>>

After Xen 3.0.5, renaming is needed :-)

>Within HVM domain:
>Echo "0" > /sys/devices/system/cpu/cpuN/online;
>Echo "1" > /sys/devices/system/cpu/cpuN/online; 
>
>Hvm_vcpu_reset is invoked as the result of receiving vINIT, which 
>then goes to hvm_vcpu_initialise, vmx_vcpu_initialise, vmx_create_vmcs.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/4/07 07:45, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> Within HVM domain:
> Echo "0" > /sys/devices/system/cpu/cpuN/online;
> Echo "1" > /sys/devices/system/cpu/cpuN/online;
> 
> Hvm_vcpu_reset is invoked as the result of receiving vINIT, which
> then goes to hvm_vcpu_initialise, vmx_vcpu_initialise,
> vmx_create_vmcs.
Ah. Ok. :-)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/4/07 07:09, "Tian, Kevin" <kevin.tian@intel.com> wrote:
> Clear whole page when VMCS is reused due to cpu hotplug.
> construct_vmcs doesn''t take care of all fields and some stale
> content may make hardware unhappy.
You almost certainly need to vmx_clear_vmcs() before you zap it, as
there''s
no reason it might not be active on some CPU when vmx_create_vmcs() is
called (domain_pause() does not deactivate VMCSs).

Furthermore, this need to zap the page a second time is worrying. We only
modify architectural state in the VMCS in a well-defined way. That
shouldn''t
upset the hardware. Is this actually an indication that there is some
architectural state that we are forgetting to re-initialise? If so then
that''s the bug which should be fixed.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年4月30日 15:12
>
>On 30/4/07 07:09, "Tian, Kevin" <kevin.tian@intel.com>
wrote:
>
>> Clear whole page when VMCS is reused due to cpu hotplug.
>> construct_vmcs doesn''t take care of all fields and some stale
>> content may make hardware unhappy.
>
>You almost certainly need to vmx_clear_vmcs() before you zap it, as
>there''s
>no reason it might not be active on some CPU when vmx_create_vmcs()
>is
>called (domain_pause() does not deactivate VMCSs).
You''re exactly right. :-)
>
>Furthermore, this need to zap the page a second time is worrying. We
>only
>modify architectural state in the VMCS in a well-defined way. That
>shouldn''t
>upset the hardware. Is this actually an indication that there is some
>architectural state that we are forgetting to re-initialise? If so then
>that''s the bug which should be fixed.
>
Does construct_vmcs need to explicitly care all fields if hardware 
just expects a zero there which can be satisfied by memset()? Anyway, 
I''ll take a deeper look to check which unexpected fields are with stale
content before reset.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/4/07 08:19, "Tian, Kevin" <kevin.tian@intel.com> wrote:
>> Furthermore, this need to zap the page a second time is worrying. We
>> only
>> modify architectural state in the VMCS in a well-defined way. That
>> shouldn''t
>> upset the hardware. Is this actually an indication that there is some
>> architectural state that we are forgetting to re-initialise? If so then
>> that''s the bug which should be fixed.
> 
> Does construct_vmcs need to explicitly care all fields if hardware
> just expects a zero there which can be satisfied by memset()? Anyway,
> I''ll take a deeper look to check which unexpected fields are with
stale
> content before reset.
Well, we actually write lots of zeroes in construct_vmcs(), so it''s not
like
we really take advantage of the memset(). And in fact strictly speaking I
don''t think we can -- the only architectural interface to the VMCS is
via
the stupid VMREAD/VMWRITE instructions. We can make no assumptions about
VMCS layout nor, presumably, field encodings (you might choose to write 1s
for 0s and 0s for 1s in the actual in-memory format, for all I know!).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
>Sent: 2007年4月30日 15:25
>
>Well, we actually write lots of zeroes in construct_vmcs(), so it''s
not like
>we really take advantage of the memset(). And in fact strictly speaking I
>don''t think we can -- the only architectural interface to the VMCS
is via
>the stupid VMREAD/VMWRITE instructions. We can make no
>assumptions about
>VMCS layout nor, presumably, field encodings (you might choose to
>write 1s
>for 0s and 0s for 1s in the actual in-memory format, for all I know!).
>
> -- Keir
Agree.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

hi
I am using blktap,and I want to understand how does the blktap work
In the domU,there seems to be no blktap in it ,is it right?
If it is, does an application in domU access to the disk through the
frontend in domU and blktap in dom0 and then backend in dom0,or does it
just walk through frontend in domU and blktap in dom0, or how does it work?

could you help me
Thanks in advance


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel