[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
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. 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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |