Re: [Xen-devel] memaccess: skipping mem_access_send_req

[Gareth Stockwell <Gareth.Stockwell@xxxxxxx>]

On Wed, Apr 15, 2015 at 10:26:52, Ian Campbell wrote:
> > We would like to use memaccess to perform (1) - but rather than
> > pausing the VCPU in (2), instead simply directly inject the
> > exception into the VCPU.
>
> That is, into the VCPUs whose permissions have been modified behind
> its back and not into some controlling domain?

Correct - the abort should be injected into the VCPU which initiated the 
invalid transaction.

> Is the guest expected to be aware of this, i.e. to be somewhat
> paravirtualised? I suppose it must have to be in order to accept
> seemingly spurious page faults.
>
> Which leads me to wonder whether an extra shared ring between the
> hypervisor and target VCPU would be desirable, i.e. to allow more fine
> grained semantics than just "computer says no". Specifically if you
> need to care about the reason for the fault being the actions of an
> external arbiter rather than some other guest-internal thing.
>
> If your application is just to allow the guest OS to kill a process
> which has tried to touch memory in a way which the external controller
> has disallowed then a page fault seems like a simple and effective way though.

The guest will be aware of the permission changes - in fact in our system 
permission changes are only enacted following a request from the guest itself.  
So, a data abort is sufficient - the guest should then be able to work that 
this was due to it violating its stage-2 permissions, and kill the appropriate 
process.

> > b) Define new xenmem_access_t values which cause the exception
> handler
> > to reinject rather than adding a message to the ring buffer.
>
> I'm no xenaccess guru but that's the option I'd be inclined to take.
>
> My only concern would be limitations on the number of xenaccess types.
> On ARM we couldn't fit the type into the spare P2M PTE bits so we will
> already have a separate lookup and therefore not much limitation, but
> I don't know about on x86.

It seems to be the simplest approach, and based on some quick prototyping 
appears to work - at least on ARM.


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel