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

Re: [PATCH v3 6/9] x86/HVM: convert hvm_virtual_to_linear_addr() to be remote-capable


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 23 Sep 2021 12:34:48 +0200
  • 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; bh=xsJR4mBTsBcRuYBVyViNw9g/7NDrTvKyGR8IzJp0MYY=; b=IfB3iJUNnrog4hT9XiynxOCYzAFiRHBdpkGWZxDvd0bcD3Z/8JuK/ctBKwJs4r09gI2902m5TV9yz8Ww/zSRqf0oG12bFKmOIbjsQgMCpMH8n+su5Q9bVMQ8220U6JgSr/QHzHd49ahjajVCSxIS+prHKCX0Pu62HUgyhK282+i3MqUAbCYGIuvxq5Q/nBOX29oWJ6PCEVHIakp+cj6BcYF63rNMooWzdnseJtQ9q54i3saWEppkRRQNSS/QCgpiR7V+zK9jQeAAujGifs9x2cnV2rTLCZK+xngPP6ehOCZcN17xMYGf3a5AV8HHxG5DvhXcZvIY/hDV5CDaPnM/lg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I0aGng4EfmqVXinLUonr6tbR7QFH3bWMi9NvYWrBc2z2ieBG4mdP1z0ZOMQkXMt/tML1YjhzD6Ok5hZUp/+W0xGxvZmni62WveKVIpZd/sV7wLt+v+wlVu6G5xLtiIQDBIVkqX8JymCUSHlkHFBREmYAFHG49JXnn+fx20JGe/TpditOsf2MiNUN8XzKJe8qAvDCvMW1NLVmp1qM1Y+F9Wcu2ZtqINWJ3VL9l68JcgIeCSHaZ9hKL9a6S56SoVpWo0O9vqxP+5GBXfNo8zxMd/p0D9hau32pf48agU08fbXrLHFOpG1nYItCc0Kwz8BP7vWyT1J7J+4Gk4kWxLM7rw==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Thu, 23 Sep 2021 10:34:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.09.2021 10:09, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 09:19:37AM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2526,7 +2526,8 @@ int hvm_set_cr4(unsigned long value, boo
>>      return X86EMUL_OKAY;
>>  }
>>  
>> -bool_t hvm_virtual_to_linear_addr(
>> +bool hvm_vcpu_virtual_to_linear(
>> +    struct vcpu *v,
>>      enum x86_segment seg,
>>      const struct segment_register *reg,
>>      unsigned long offset,
>> @@ -2535,8 +2536,9 @@ bool_t hvm_virtual_to_linear_addr(
>>      const struct segment_register *active_cs,
>>      unsigned long *linear_addr)
>>  {
>> -    const struct vcpu *curr = current;
>>      unsigned long addr = offset, last_byte;
>> +    const struct cpu_user_regs *regs = v == current ? guest_cpu_user_regs()
>> +                                                    : &v->arch.user_regs;
>>      bool_t okay = 0;
> 
> Since you change the function return type to bool, you should also
> change the type of the returned variable IMO. It's just a two line
> change.

Can do; I would have viewed this as an unrelated change: While the
first change needed indeed is on an adjacent line (above), the other
one isn't.

> Also is it worth adding some check that the remote vCPU is paused? Or
> else you might get inconsistent results by using data that's stale  by
> the time Xen acts on it.

I did ask myself the same question. I did conclude that even if the
remote vCPU is paused at the time of the check, it may not be anymore
immediately after, so the information returned might be stale anyway.
I further looked at {hvm,vmx}_get_segment_register() to see what they
did - nothing. It is only now that I've also checked
svm_get_segment_register(), which - interestingly - has such a check.
I will copy the ASSERT() used there.

Jan




 


Rackspace

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