From mboxrd@z Thu Jan  1 00:00:00 1970
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH 2/5] xen/vm_access: Support for
 memory-content hiding
Date: Sat, 09 May 2015 09:55:19 +0300
Message-ID: <554DAF57.3060105@bitdefender.com>
References: <1430932352-4289-1-git-send-email-rcojocaru@bitdefender.com>	<1430932352-4289-3-git-send-email-rcojocaru@bitdefender.com>	<554CFB760200007800078703@mail.emea.novell.com>	<554CE8FC.5040305@bitdefender.com>
	<CAErYnshJ_r2Jt5=EMUSBqzk+=Oq+4u0xLwnEuV0axXQ8quHDRw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAErYnshJ_r2Jt5=EMUSBqzk+=Oq+4u0xLwnEuV0axXQ8quHDRw@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, "Tian,
	Kevin" <kevin.tian@intel.com>, "wei.liu2@citrix.com" <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Jun Nakajima <jun.nakajima@intel.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, "Dong,
	Eddie" <eddie.dong@intel.com>, "Aravind.Gopalakrishnan@amd.com" <Aravind.Gopalakrishnan@amd.com>, Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>
List-Id: xen-devel@lists.xenproject.org

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