Re: [Xen-devel] Scalable Event Channel ABI design (draft A)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, 2013-02-06 at 10:52 +0000, Ian Campbell wrote:
> On Wed, 2013-02-06 at 10:42 +0000, Wei Liu wrote:
> > On Wed, 2013-02-06 at 09:38 +0000, Ian Campbell wrote:
> > > On Tue, 2013-02-05 at 18:02 +0000, Keir Fraser wrote:
> > > > On 05/02/2013 16:11, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
> > > > 
> > > > >>> Okay, I wonder how much it actually matters anyhow...
> > > > >>> 
> > > > >>> Oh by the way you say the control block is 128 bytes and will 
> > > > >>> easily fit in
> > > > >>> the existing struct vcpu_info. That existing structure is 64 bytes 
> > > > >>> in total.
> > > > >>> So how does that work then?
> > > > >> 
> > > > >> I meant struct vcpu_info can be extended without it growing to more 
> > > > >> than
> > > > >> a page.  i.e., it fits into the guest page provided in the
> > > > >> VCPUOP_register_vcpu_info call so no additional pages need to be
> > > > >> globally mapped for the control block.
> > > > > 
> > > > > VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a 
> > > > > page
> > > > > by itself, even if that happens to be the Linux implementation today 
> > > > > (I
> > > > > haven't checked that).
> > > > 
> > > > Having guest agree that vcpu_info grows by size of the per-vcpu control
> > > > block, if using this new event-channel interface, is reasonable though.
> > > 
> > > Can only use this trick once though, so it might be blocking ourselves
> > > into a future ABI corner.
> > > 
> > 
> > In practice embedding control block in vcpu_info might not be feasible
> > because there is a legacy array of vcpu_info in shared_info page. It is
> > quite easy to bloat shared_info to exceed size limit.
> 
> I don't think we need to literally add the control block to struct
> vcpu_info, just require that it immediately follows the vpcu_info. This
> new interface requires the use of vcpu_info placement so the legacy
> array is not a concern.
> 
> > > Is there a downside to registering the control block separately? The
> > > guest can always arrange for them to be contiguous if it wants, or if we
> > > are worried about the number of global mappings then the hypervisor
> > > could require it shares a page with the vcpu_info but allow the offset
> > > to be specified separately.
> > > 
> > 
> > IMHO the global mapping space is the main concern. Regarding sharing
> > page with vcpu_info, this requires us to control the way kernel handles
> > its per-cpu section. But how?
> 
> We simply require that the kernel do it right...
> 
> In this instance you would probably do:
>       struct per_vcpu_info {
>               struct vcpu_info ...;
>               struct evtchn_control ...;
>       }
> and allocate that in per-cpu space. Or is there concern that this
> allocation might cross a page boundary? I think it is required to be
> naturally aligned (i.e. aligned to at least its own size) so that is ok.
> 

I get what you mean. ;-)

My other concern is, along this path we can save global mapping address
space, but now the burden of enabling the new interface somewhat slip to
the vcpu placement hypercall other than HYPERVISOR_event_channel_op. If
you're fine with this I will be OK too.


Wei.

> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel