[Xen-devel] Re: [RFC, PATCH 1/24] i386 Vmi documentation

[Chris Wright <chrisw@xxxxxxxxxxxx>]

* Zachary Amsden (zach@xxxxxxxxxx) wrote:
> >1) can't use stack based args, so have to allocate each data structure,
> >which could conceivably fail unless it's some fixed buffer.
> 
> We use a fixed buffer that is private to our VMI layer.  It's a per-cpu 
> packing struct for hypercalls.  Dynamically allocating from the kernel 
> inside the interface layer is a really great way to get into a whole lot 
> of trouble.

Heh, indeed that's why I asked.  per-cpu buffer means ROM state knows
which vcpu is current.  How is this done in OS agnostic method w/out
trapping to hypervisor?  Some shared data that ROM and VMM know about,
and VMM updates as it schedules each vcpu?

> >2) complicates the rom implementation slightly where implementation of
> >each deferrable part of the API needs to have switch (am I deferred or
> >not) to then build the batch, or make direct hypercall.
> 
> This is an overhead that is easily absorbed by the gain.  The direct 
> hypercalls are mostly either always direct, or always queued.  The page 
> table updates already have conditional logic to do the right thing, and 
> Xen doesn't require the queueing of these anymore anyways.  And the 
> flush happens at an explicit point.  The best approach can still be fine 
> tuned.  You could have separate VMI calls for queued vs. non-queued 
> operation.  But that greatly bloats the interface and doesn't make sense 
> for everything.  I believe the best solution is to annotate this in the 
> VMI call itself.  Consider the VMI call number, not as an integer, but 
> as an identifier tuple.  Perhaps I'm going overboard here.  Perhaps not.
> 
> 31--------24-23---------16-15--------8-7-----------0
> | family   | call number | reserved  | annotation |
> ---------------------------------------------------

I agree with your final assessment, needs more threshing out.  It does
feel a bit overkill at first blush.  I worry about these semantic
changes as an annotation instead of explicit API update.  But I guess
we still have more work on finding the right actual interface, not just
the possible ways to annotate the calls.

thanks,
-chris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel