Xen devel - Dec 2011 - [PATCH] Flag events caused by foreign domains

xen/arch/x86/mm/mem_event.c    |  6 ++++++
 xen/include/public/mem_event.h |  1 +
 2 files changed, 7 insertions(+), 0 deletions(-)


Add a new flag for mem events, as consumers might need to discriminate
foreign domain-caused from guest-caused events. The vcpu field of an
event is bogus from a consumer p.o.v. for foreign domain-caused events.

Also assert that we shouldn''t be pausing foreign vcpus.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -143,6 +143,12 @@ void mem_event_put_request(struct domain
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
+    if ( current->domain != d )
+    {
+        req->flags |= MEM_EVENT_FLAG_FOREIGN;
+        ASSERT( !(req->flags & MEM_EVENT_FLAG_VCPU_PAUSED) );
+    }
+
     /* Copy request */
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
diff -r 8ad7af68e017 -r 2a4ec2e2ae36 xen/include/public/mem_event.h
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -39,6 +39,7 @@
 #define MEM_EVENT_FLAG_VCPU_PAUSED  (1 << 0)
 #define MEM_EVENT_FLAG_DROP_PAGE    (1 << 1)
 #define MEM_EVENT_FLAG_EVICT_FAIL   (1 << 2)
+#define MEM_EVENT_FLAG_FOREIGN      (1 << 3)
 
 /* Reasons for the memory event request */
 #define MEM_EVENT_REASON_UNKNOWN     0    /* typical reason */

On Thu, Dec 01, Andres Lagar-Cavilla wrote:
> Add a new flag for mem events, as consumers might need to discriminate
> foreign domain-caused from guest-caused events. The vcpu field of an
> event is bogus from a consumer p.o.v. for foreign domain-caused events.
How is this supposed to be used?

If the toolstack is going to use this then I have to say that it cant
delay events much because the ring will be filled up quickly with the
result that no more events can be generated until the toolstack sends
responses back to the hypervisor.

Olaf

> On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>
>> Add a new flag for mem events, as consumers might need to discriminate
>> foreign domain-caused from guest-caused events. The vcpu field of an
>> event is bogus from a consumer p.o.v. for foreign domain-caused events.
>
> How is this supposed to be used?
We''re just OR''ing an extra flag on existing events. Toolstacks
can ignore
it, or use it to handle foreign events differently, or whatever. No new
events are generated, timings don''t change etc.

Is that your concern?
Andres
>
> If the toolstack is going to use this then I have to say that it cant
> delay events much because the ring will be filled up quickly with the
> result that no more events can be generated until the toolstack sends
> responses back to the hypervisor.
>
> Olaf
>

On Fri, Dec 02, Andres Lagar-Cavilla wrote:
> > On Thu, Dec 01, Andres Lagar-Cavilla wrote:
> >
> >> Add a new flag for mem events, as consumers might need to
discriminate
> >> foreign domain-caused from guest-caused events. The vcpu field of
an
> >> event is bogus from a consumer p.o.v. for foreign domain-caused
events.
> >
> > How is this supposed to be used?
> We''re just OR''ing an extra flag on existing events.
Toolstacks can ignore
> it, or use it to handle foreign events differently, or whatever. No new
> events are generated, timings don''t change etc.
Thats obvious.
> Is that your concern?
I''m wondering wether it really achieves what you want, no stall in the
ring buffer etc.

Olaf

> On Fri, Dec 02, Andres Lagar-Cavilla wrote:
>
>> > On Thu, Dec 01, Andres Lagar-Cavilla wrote:
>> >
>> >> Add a new flag for mem events, as consumers might need to
>> discriminate
>> >> foreign domain-caused from guest-caused events. The vcpu field
of an
>> >> event is bogus from a consumer p.o.v. for foreign
domain-caused
>> events.
>> >
>> > How is this supposed to be used?
>> We''re just OR''ing an extra flag on existing events.
Toolstacks can
>> ignore
>> it, or use it to handle foreign events differently, or whatever. No new
>> events are generated, timings don''t change etc.
>
> Thats obvious.
>
>> Is that your concern?
>
> I''m wondering wether it really achieves what you want, no stall in
the
> ring buffer etc.
That''s not what I want with this patch...
Andres
>
> Olaf
>

On Fri, Dec 02, Andres Lagar-Cavilla wrote:
> > I''m wondering wether it really achieves what you want, no
stall in the
> > ring buffer etc.
> That''s not what I want with this patch...
Sure. 
Anyway, I''m not against this change.

Olaf