Re: [Xen-devel] [PATCH v10 1/6] x86: detect and initialize Cache QoS Monitoring feature

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, April 03, 2014 4:47 PM
> To: Xu, Dongxiao
> Cc: andrew.cooper3@xxxxxxxxxx; Ian.Campbell@xxxxxxxxxx;
> Ian.Jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
> xen-devel@xxxxxxxxxxxxx; dgdegra@xxxxxxxxxxxxx; keir@xxxxxxx
> Subject: RE: [Xen-devel] [PATCH v10 1/6] x86: detect and initialize Cache QoS
> Monitoring feature
> 
> >>> On 03.04.14 at 10:27, <dongxiao.xu@xxxxxxxxx> wrote:
> >> From: xen-devel-bounces@xxxxxxxxxxxxx
> >> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Jan Beulich
> >> But you could get away with a split approach: Provide the socket ID
> >> list via ordinary hypercall means (if this isn't already derivable from
> >> the topology sysctl anyway), and only share the per-socket data
> >> page(s).
> >
> > sysctl->u.getcqminfo has size limitation of 128 bytes.
> > The per-socket MFN array _may_ exceed this limitation...
> >
> > We discussed this issue in previous threads, that's how this 2-level of
> > data_mfn/data page sharing mechanism is proposed.
> 
> That's unrelated - you can always introduce a handle pointing to the
> array where the MFNs are to be stored. Whether that's preferable
> over the shared page approach largely depends on the number of
> entries in the page, and the performance needs. Both I think would
> suggest to use the handle-to-array approach, and use shared pages
> only for the actual data.

I am okay with either solution, whatever share or copy.

The 2-level sharing is previously proposed by Andrew, which I implemented in 
v10.
Andrew, are you okay with this copy solution for the MFN page?

Thanks,
Dongxiao

> 
> Jan


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