[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 12/16] x86/shadow: make monitor table create/destroy more consistent


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 24 Mar 2023 08:52:36 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=N68Wac8O41rHbpwkvwzk9JNgrB8PmP9/1ATul2QjbGk=; b=FPYn55KxP/Kxm5+tK1A291ViN1jhCEtisWrNN3RxEu3Ov3O1SaIrCrctzNTi6VJ96SWKfAoUoBHLN9HFi0sk4CH1d3q+wOCDL6SbQ6paq2bwt6ddbyPP9gifpeqgzFCFP6o9VhIcek2k/svyLsCrc7Yx6rnb2ydfmrimxSwM7ip4RoPgtCZhuh/7I2aPGjHcZXw7Kwvy1np3ZDvS/4K7zkiefiUNN3aRLBkCMOqmE5bWIN1/0YmO5jbA4e3AwgRBv1jP5h3ldvFZyfMrqNcYdzjf+/AtbgFMkMQCl2BgphOoNbAHdZ3Jgxu4fYvQv/Cyuukuk+1NCYyIvVzrDPiJkA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=esesW4DY8ENN0b0H3QtYL1KZhPOzf2z1e54abWPfzRmAo79fg0rYzenizVGPMjtEVym+RyUVvgLCC4xTa1pU5gC3myKJCD14iBslnHcCO9ULtEsRZdv9fKq3Yn4HQIUIS8B2850lOFLWketHBXG9ffLeQ0XJfZFu8f6X1ZnLP7w2JunkX2Bu8LnDfU9thKFcH3UhF73F36JlINfjZAd1no+sCugu4nG8aEfjWy2L1GcJmTTtgbS575sR8goSkUoG8SzZ6cMhQON82tmAckAxvLYgk9tBr2vB/i1v2JsdNLy1HW4wErXHWCiM5MSF8wqNOyhs1oScL8eL+5eUYOo4Zg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 24 Mar 2023 07:52:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.03.2023 19:28, Andrew Cooper wrote:
> On 22/03/2023 9:35 am, Jan Beulich wrote:
>> While benign at present, it is still a little fragile to operate on a
>> wrong "old_mode" value in sh_update_paging_modes(). This can happen when
>> no monitor table was present initially - we'd create one for the new
>> mode without updating old_mode. Correct this two ways, each of which
> 
> I think you mean "Correct this in two ways" ?
> 
>> would be sufficient on its own: Once by adding "else" to the second of
>> the involved if()s in the function, and then by setting the correct
>> initial mode for HVM domains in shadow_vcpu_init().
>>
>> Further use the same predicate (paging_mode_external()) consistently
>> when dealing with shadow mode init/update/cleanup, rather than a mix of
>> is_hvm_vcpu() (init), is_hvm_domain() (update), and
>> paging_mode_external() (cleanup).
>>
>> Finally drop a redundant is_hvm_domain() from inside the bigger if()
>> (which is being converted to paging_mode_external()) in
>> sh_update_paging_modes().
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/xen/arch/x86/mm/shadow/common.c
>> +++ b/xen/arch/x86/mm/shadow/common.c
>> @@ -129,8 +129,8 @@ void shadow_vcpu_init(struct vcpu *v)
>>      }
>>  #endif
>>  
>> -    v->arch.paging.mode = is_hvm_vcpu(v) ?
>> -                          &SHADOW_INTERNAL_NAME(sh_paging_mode, 3) :
>> +    v->arch.paging.mode = paging_mode_external(v->domain) ?
>> +                          &SHADOW_INTERNAL_NAME(sh_paging_mode, 2) :
>>                            &SHADOW_INTERNAL_NAME(sh_paging_mode, 4);
> 
> As you're changing this, reposition the ? and : to the start of the
> following lines?

Sure.

> But, is 2-level mode actually right?  It's better than 3 certainly, and
> is what sh_update_paging_modes() selects, but isn't that only right for
> the IDENT_PT case?

Which is how HVM vCPU-s start, isn't it? For PVH there clearly needs to
be a separate (later) paging mode update anyway (or else what - as you
say - sh_update_paging_modes() selects would also be wrong), which is
going to be whenever we see CR0.PG becoming set by the toolstack.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.