Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.09.17 at 16:56, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Jan
>> Beulich
>> Sent: 25 September 2017 15:50
>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxxxxxxxxx 
>> Subject: Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV
>> domain to map guest mfns
>> 
>> >>> On 25.09.17 at 16:42, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: 25 September 2017 14:03
>> >> >>> On 18.09.17 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
>> >> The other aspect I don't understand is why this is needed for PV
>> >> Dom0, but not for PVH. The answer here can't be "because PVH
>> >> Dom0 isn't supported yet", because it eventually will be, and then
>> >> there will still be the problem of PVH supposedly having no notion
>> >> of MFNs (be their own or foreign guest ones). The answer also
>> >> can't be "since it would use XENMAPSPACE_gmfn_foreign", as
>> >> that's acting in terms of GFN too.
>> >
>> > The hypercall is PV-only. For a PVH/HVM tools domain things are handled
>> by
>> > doing an add-to-physmap to gfns specified by the tools domain. I have
>> tested
>> > both PV and HVM clients of my new memory op.
>> 
>> And how is this add-to-physmap any better superpage shattering
>> wise than the old mechansim?
> 
> Because the calling domain can make an intelligent choice about what gfns to 
> use?

And why was an intelligent choice not possible with the old
mechanism? The calling domain is the tool stack one in both
cases, isn't it?

Jan


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