Re: [PATCH v2 1/6] x86/xpti: avoid copying L4 page table contents when possible

["Jan Beulich" <JBeulich@suse.com>]

>>> On 06.03.18 at 09:06, <jgross@suse.com> wrote:
> On 06/03/18 08:58, Jan Beulich wrote:
>>>>> On 06.03.18 at 08:01, <jgross@suse.com> wrote:
>>> On 05/03/18 17:43, Jan Beulich wrote:
>>>>>>> On 02.03.18 at 09:13, <jgross@suse.com> wrote:
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -509,6 +509,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>>>>  
>>>>>  void write_ptbase(struct vcpu *v)
>>>>>  {
>>>>> +    get_cpu_info()->root_pgt_changed = this_cpu(root_pgt) && is_pv_vcpu(v) &&
>>>>> +                                       !is_pv_32bit_vcpu(v);
>>>>
>>>> Why is_pv_vcpu() when you already check is_pv_32bit_vcpu()?
>>>
>>> I check !is_pv_32bit_vcpu() to catch 64-bit pv-domains only.
>> 
>> Oh, I'm sorry - For whatever reason I've ignored the ! there.
>> 
>>>> And don't you need to disallow updating L4s of running guests now
>>>> (which is a bad idea anyway)?
>>>
>>> Yes, I should do that.
>> 
>> But please do this as a separate change, as strictly speaking this is
>> a behavioral change that we can't allow. But I think we simply need
>> to accept this (and perhaps uniformly for all page table levels).
> 
> Hmm, thinking more about it: wouldn't it be enough to do the change and
> then sending a FLUSH_ROOT_PGTBL to the vcpu(s) the affected guest is
> running on? This would cause a cycle through the hypervisor resulting in
> an updated root page table of that guest.

Ah, yes, of course. That was the idea behind the original addition
of the flush invocation after all.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel