Re: [Xen-devel] [PATCH RFC v12 07/21] pvh: Disable unneeded features of HVM containers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.09.13 at 16:43, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 18/09/13 15:18, Jan Beulich wrote:
>>>>> On 13.09.13 at 18:25, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/hvm/io.c
>>> +++ b/xen/arch/x86/hvm/io.c
>>> @@ -175,6 +175,10 @@ int handle_mmio(void)
>>>       struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
>>>       int rc;
>>>   
>>> +    /* No MMIO for PVH vcpus */
>>> +    if ( is_pvh_vcpu(curr) )
>>> +        return 0;
>>> +
>> So why does hvm_pio() not get adjusted similarly?
> 
> At the moment I don't think hvm_pio() will be called for PVH guests.  IO 
> instructions for PVH domains are handled by the PV io emulation engine.  
> The check here is to make sure that Xen doesn't try to do MMIO for PVH 
> domains on an EPT violation.  Mukesh had an "if(!is_pvh_domain)" in the 
> EPT handler before calling hvm_hap_nested_page_fault(), which not only 
> filtered out MMIO, but also any other reason the fault may have happened 
> (e.g., paging or a mem event).
> 
> I put the check in handle_mmio() instead of hvm_hap_nested_page_fault() 
> just in case there was another path to that function.  I suppose the 
> same logic applies to hvm_pio(). We could put either an ASSERT or just a 
> check that returns failure.  (I would lean toward an ASSERT.)

Yes, an ASSERT() would be fine, restoring consistency.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel