Re: [Xen-devel] [PATCH RFC v2 1/3] xen/pvh: enable mmu_update hypercall

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/04/15 13:43, Jürgen Groß wrote:
> On 04/02/2015 01:50 PM, Andrew Cooper wrote:
>> On 02/04/15 11:42, Ian Campbell wrote:
>>> On Thu, 2015-04-02 at 12:26 +0200, Roger Pau Monne wrote:
>>>> This is needed for performing save/restore of PV guests.
>>> It's quite a big interface though, isn't it?
>>>
>>> Could we restrict it to a subset of the operations perhaps? Or at least
>>> justify here how it has been audited and found to be safe to allow an
>>> HVM guest this access.
>>
>> It isn't actually very big, but does have quite a lot of PV knowledge
>> built in.
>>
>> I would be happer with the safety of this patch if
>> v->arch.old_guest_table got moved into the pv union, to make the code
>> much clearer that it is specifically for PV guests.
>>
>> If I recall, this change only needed for MMU_MACHPHYS_UPDATE against a
>> foreign domain.  Each of the 3 subops does check for
>> paging_mode_translate/refcounts() of the target, which does prevent the
>> hypercall being made against a non-PV domains.  From that point of view,
>> it should be safe for HVM guests to use, as it is the target domain,
>> rather than the source domain, which is important.
>>
>>
>> However, with migration v2 dropping support for 2-level PV guests (which
>> died with the 32bit hypervisor build), I believe I have removed all need
>> for MMU_MACHPHYS_UPDATE hypercalls entirely (unless there are some done
>> behind the scenes from the kernel).
>
> There is one usage in the kernel in file arch/x86/xen/setup.c targeting
> DOMID_SELF.

Right, but that looks to be a codepath which is only used in PV guests.

All that matters (from the point of view of this patch) is whether any
toolstack actions result in the issue of mmu_update hypercalls.

If migration v2 has removed the need for any MMU_MACHPHYS_UPDATE ops
(which I believe it has), then Xen need not expose the do_mmu_update()
hypercall to non-PV guests.

~Andrew

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