All of lore.kernel.org
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
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>
Subject: Re: [PATCH 2/5] xen/vm_access: Support for memory-content hiding
Date: Sat, 09 May 2015 09:55:19 +0300	[thread overview]
Message-ID: <554DAF57.3060105@bitdefender.com> (raw)
In-Reply-To: <CAErYnshJ_r2Jt5=EMUSBqzk+=Oq+4u0xLwnEuV0axXQ8quHDRw@mail.gmail.com>

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

  reply	other threads:[~2015-05-09  6:55 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 17:12 [PATCH 0/5] Vm_event memory introspection helpers Razvan Cojocaru
2015-05-06 17:12 ` [PATCH 1/5] xen/vm_event: Added support for XSETBV events Razvan Cojocaru
2015-05-07 15:43   ` Tim Deegan
2015-05-07 17:44     ` Andrew Cooper
2015-05-07 18:03   ` Andrew Cooper
2015-05-08  6:18     ` Razvan Cojocaru
2015-05-08  7:31       ` Jan Beulich
2015-05-08  9:06     ` Razvan Cojocaru
2015-05-08  9:10       ` Andrew Cooper
     [not found]         ` <CAErYnsh=N9AvoKFUN+i2oyF_fyQhGY2u4wO=v6y7hXP-thXi+g@mail.gmail.com>
     [not found]           ` <554C9606.7070103@citrix.com>
2015-05-08 11:05             ` Tamas K Lengyel
2015-05-08 11:52               ` Jan Beulich
2015-05-08 12:09                 ` Razvan Cojocaru
2015-05-08 12:39                   ` Tamas K Lengyel
2015-05-08 12:21   ` Jan Beulich
2015-05-08 12:23     ` Razvan Cojocaru
2015-05-06 17:12 ` [PATCH 2/5] xen/vm_access: Support for memory-content hiding Razvan Cojocaru
2015-05-08 16:07   ` Jan Beulich
2015-05-08 16:49     ` Razvan Cojocaru
2015-05-08 23:34       ` Tamas K Lengyel
2015-05-09  6:55         ` Razvan Cojocaru [this message]
2015-05-09  8:33           ` Tamas K Lengyel
2015-05-09 15:11             ` Razvan Cojocaru
2015-05-11  7:50           ` Jan Beulich
2015-05-11  7:00       ` Jan Beulich
2015-06-08 10:02     ` Razvan Cojocaru
2015-06-08 10:20       ` Jan Beulich
2015-05-06 17:12 ` [PATCH 3/5] xen/vm_event: Support for guest-requested events Razvan Cojocaru
2015-05-07 17:05   ` Tamas K Lengyel
2015-05-07 17:43     ` Razvan Cojocaru
2015-05-08 11:00       ` Tamas K Lengyel
2015-05-08 16:16   ` Jan Beulich
2015-05-08 16:38     ` Razvan Cojocaru
2015-05-08 16:50   ` Andrew Cooper
2015-06-09 12:44     ` Razvan Cojocaru
2015-05-06 17:12 ` [PATCH 4/5] xen/vm_event: Deny MSR writes if refused by vm_event reply Razvan Cojocaru
2015-05-08 16:23   ` Jan Beulich
2015-05-08 17:05     ` Razvan Cojocaru
2015-05-11  7:03       ` Jan Beulich
2015-05-11  7:44         ` Razvan Cojocaru
2015-05-06 17:12 ` [PATCH 5/5] xen: Write CR0, CR3 and CR4 in arch_set_info_guest() Razvan Cojocaru
2015-05-13 12:11   ` Boris Ostrovsky
2015-05-15 15:57   ` Jan Beulich
2015-05-15 20:45     ` Razvan Cojocaru
2015-05-15 23:13       ` Andrew Cooper
2015-05-16  7:19         ` Razvan Cojocaru
2015-05-17 18:32           ` Tamas K Lengyel
2015-05-18  7:37             ` Razvan Cojocaru
2015-05-19 10:14               ` Tamas K Lengyel
2015-05-19 10:31                 ` Jan Beulich
2015-05-19 10:45                   ` Tamas K Lengyel
2015-05-19 13:45                     ` Jan Beulich
2015-05-20 15:57                       ` Tamas K Lengyel
2015-05-19 12:10                 ` Razvan Cojocaru
2015-05-18  7:27       ` Jan Beulich
2015-05-18  7:58         ` Razvan Cojocaru
2015-05-18  8:05           ` Jan Beulich
2015-05-18  8:11             ` Razvan Cojocaru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=554DAF57.3060105@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tamas.lengyel@zentific.com \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.