Re: [Xen-devel] [PATCH for 4.9 1/6] x86/hvm: Correct some address space terminology

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.04.17 at 12:19, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 03/04/17 09:24, Jan Beulich wrote:
>>>>> On 31.03.17 at 21:50, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/mm/shadow/common.c
>>> +++ b/xen/arch/x86/mm/shadow/common.c
>>> @@ -136,13 +136,13 @@ static struct segment_register *hvm_get_seg_reg(
>>>      return seg_reg;
>>>  }
>>>  
>>> -static int hvm_translate_linear_addr(
>>> +static int hvm_translate_virtual_addr(
>>>      enum x86_segment seg,
>>>      unsigned long offset,
>>>      unsigned int bytes,
>>>      enum hvm_access_type access_type,
>>>      struct sh_emulate_ctxt *sh_ctxt,
>>> -    unsigned long *paddr)
>>> +    unsigned long *linear)
>> ... here would be useful (to distinguish the virtual address
>> represented by the pointer itself - in hypervisor space - from the
>> one the pointer points to, i.e. in guest space).
> 
> The virtual address representation is {seg, offset}, and Xen can't use
> linear addresses.

Oops, I'm sorry, I meant linear, not virtual. And of course Xen uses
linear addresses (in hypervisor address space) all the time (due to
virtual == linear in 64-bit mode, leaving aside the few exceptions;
in particular we never pass around any {seg, offset} pairs to
represent hypervisor pointers). I.e. once the function has written
*linear we have two linear addresses here:
- "linear" itself represents one (hypervisor, pointer type)
- "*linear" holds another (guest, integral type)

Jan


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