>>> On 04.08.16 at 11:32, <andrew.coop...@citrix.com> wrote:
> On 04/08/16 08:23, Jan Beulich wrote:
>>>>> On 03.08.16 at 23:00, <rcojoc...@bitdefender.com> wrote:
>>> On 08/03/16 23:44, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>> @@ -5194,8 +5194,14 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>>>> switch ( mode )
>>>> {
>>>> case 8:
>>>> + if ( eax == __HYPERVISOR_hvm_op &&
>>>> + regs->rdi == HVMOP_guest_request_vm_event )
>>>> + break;
>>>> case 4:
>>>> case 2:
>>>> + if ( eax == __HYPERVISOR_hvm_op &&
>>>> + regs->ebx == HVMOP_guest_request_vm_event )
>>>> + break;
>>>> hvm_get_segment_register(curr, x86_seg_ss, &sreg);
>>>> if ( unlikely(sreg.attr.fields.dpl) )
>>>> {
>>> Indeed, if everyone agrees that the patch is acceptable I'm happy to
>>> send it to xen-devel. It'd obviously be great if this ends up upstream.
>> Well, I'm not convinced special casing like this is a good idea.
>
> Why?
Primarily because such special casing doesn't scale well - what if
a 2nd, 3rd, and 4th one want passing through. The more that
such a request being embedded in a multicall would then need
special casing too.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
