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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

Ian.


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