Re: [Xen-devel] [PATCH RFC V9 4/5] xen, libxc: Request page fault injection via libxc

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 08/28/2014 03:11 PM, Jan Beulich wrote:
>>>> On 28.08.14 at 14:08, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 08/28/2014 03:03 PM, Jan Beulich wrote:
>>>>>> On 28.08.14 at 13:48, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> +    case XEN_DOMCTL_request_pagefault:
>>>> +    {
>>>> +        unsigned int vcpu = op->u.vcpucontext.vcpu;
>>>
>>> So you're using two different structures of the union - how can
>>> that possibly work? You've got a 32-bi padding field, which you can
>>> easily use to indicate the desired vCPU. Apart from that I'm not
>>> seeing how your intended "any vCPU" is now getting handled.
>>
>> Sorry about that, started from a copy / paste bug from another domctl
>> case. I'll add the vcpu field to our struct and use that.
>>
>> Not sure I follow the second part of your comment. Assuming the union
>> problem is fixed, is this not what you meant about handling the page
>> fault injection VCPU-based vs domain-based?
> 
> It is, but you said you want an "I don't care on which vCPU"
> special case. In fact with your previous explanations I could
> see you getting into trouble if on a large guest you'd have to
> wait for one particular CPU to get to carry out the desired
> swap-in.

I do, the code simply uses VCPU 0 for this now. The delay might indeed
be a problem (though not a huge one, I'll have to check), but I'm not
sure how else to strike a balance between the special case we need
(which is fine for a mem_event-based application) and the general case
(where there might not be any restrictions on the client).


Thanks,
Razvan Cojocaru

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