[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify hvm_op



>>> On 10.09.12 at 15:35, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> On 09/10/2012 02:23 PM, Jan Beulich wrote:
>>>>> On 10.09.12 at 15:02, Julien Grall<julien.grall@xxxxxxxxxx>  wrote:
>>>>>          
>>> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>>      
>>>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@xxxxxxxxxx>   wrote:
>>>>>>>
>>>>>>>              
>>>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>>>
>>>>>          
>>>>>>> switch ( a.index )
>>>>>>> {
>>>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>>>> another one below appears to be the case) is not allowed.
>>>>>>
>>>>>>
>>>>>>            
>>>>> I removed these 3 sub-ops because it will not work with
>>>>> QEMU disaggregation. Shared pages and event channel
>>>>> for IO request are private for each device model.
>>>>>
>>>>>          
>>>> Then they need to be made inaccessible for that specific setup, not
>>>> removed altogether.
>>>>
>>>>
>>>>        
>>> What do you mean by specific feature ?
>>> With this patch series, you are able to handle one or more
>>> QEMU.
>>> Keep a compatibility with the old IO emulation is hard.
>>>      
>> Did you read my original reply? Code backing operations that a
>> guest can issue itself (i.e. without qemu or another host side
>> component involved) just can't be removed, as you/we have
>> no control over which guest(s) may be making use of that
>> functionality.
>>    
> 
> Ah ok misundertanding of my part. I don't really understand
> in which case a domain needs to retrieve its ioreq page.
> How can I made it inaccessible ? Just rc = -EINVAL ?

Probably, but you'd better talk to whoever added that code
(including to determine whether this by mistake was left guest
invokable).

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.