Flag events caused by foreign domains
PATCH 1/1 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.
xen/arch/x86/mm/mem_event.c +6 -0
@@ -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++;
xen/include/public/mem_event.h +1 -0
@@ -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 */
Quoted 3 lines · Andres Lagar-Cavilla
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
Quoted 7 lines · Andres Lagar-Cavilla
Quoted 4 lines
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
Quoted 8 lines
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
Quoted 10 lines · Andres Lagar-Cavilla
Quoted 7 lines · Andres Lagar-Cavilla
Quoted 4 lines
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.
Quoted 1 line
Is that your concern?
I'm wondering wether it really achieves what you want, no stall in the ring buffer etc.
Olaf
Quoted 16 lines · Andres Lagar-Cavilla
Quoted 7 lines
Quoted 4 lines · Andres Lagar-Cavilla
Quoted 2 lines
Add a new flag for mem events, as consumers might need to
discriminate
Quoted 2 lines
Quoted 2 lines
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
Quoted 7 lines
events.
Quoted 2 lines
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.
Quoted 6 lines
Thats obvious.
Quoted 1 line
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
Quoted 3 lines
Olaf
Quoted 3 lines · Andres Lagar-Cavilla
Quoted 2 lines
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