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

Re: [Xen-devel] [PATCH 2/5] xen/vm_access: Support for memory-content hiding



On 05/09/2015 02:34 AM, Tamas K Lengyel wrote:
>>>> @@ -193,6 +200,11 @@ struct vm_event_xsetbv {
>>>> >>>      uint64_t value;
>>>> >>>  };
>>>> >>>
>>>> >>> +struct vm_event_emul_read_data {
>>>> >>> +    uint32_t size;
>>>> >>> +    uint8_t  data[164];
>>> >>
>>> >> This number needs an explanation.
>> >
>> > It's less than the size of the x86_regs and enough for all the cases
>> > we've tested so far...
>> >
>> >
>> > Thanks,
>> > Razvan
> I feel like 164 bytes is really wasteful for all vm_events considering
> this would be useful only in a very specific subset of cases. Not sure
> what would be the right way to get around that.. Maybe having another
> hypercall (potentionally under memop?) place that buffer somewhere
> where Xen can access it before the vm_event response is processed?
> That would require two hypercalls to be issued by the monitoring
> domain, one to place the buffer and one for the event channel
> notification being sent to Xen to that the response is placed on the
> ring, but it might save space on the ring buffer for all other
> cases/users.

How is it wasteful? Those bytes are in a union with the x86 registers
that are already in each vm_event request and response, and the size of
that buffer is smaller than the size of the x86 registers struct.

The buffer is simply ignored (with no effect whatsoever - on the size of
the data involved or otherwise), except for the cases where it's needed,
when the client application fills it up and sets the flag in the response.

Am I missing something?


Thanks,
Razvan

_______________________________________________
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®.