Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.01.17 at 19:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 27/01/17 16:40, Jan Beulich wrote:
>> So what we'll need to do then, as I understand it from the
>> discussion so far:
>>
>> - vmx_set_segment_register() will need to set a correct limit
>> - vmx_set_segment_register() should initialize the TSS every
>>   time (including setting the I/O bitmap address to no lower
>>   than 32)
>> - hvmloader's init_vm86_tss() will need to allocate 160 bytes
>>   rather than 128 (and we should expose this number, so that
>>   Roger can also use it)
>>
>> Perhaps we should even introduce a hypercall for hvmloader
>> to query the needed value, rather than exposing a hardcoded
>> number?
> 
> I suggest we remove all responsibility of managing this from hvmloader. 
> The only thing hvmloader does is allocate space for it, and reserve it
> in the E820.

While I did it that way for now, I'm no longer convinced this is
useful. With multiple vCPU-s, a guest can do whatever it wants to
this TSS anyway, regardless of whether Xen currently thinks it's
using a suitably initialized memory block. And whatever the guest
does, any non-zero bit in that area will only slow it down (due to
the VM exits resulting from the #GP faults caused by those 1 bits,
resulting in the respective I/O or INTnn insns being carried out by
the emulator).

> It is conceptually related to IDENT_PT, although the IDENT_PT must be
> allocated and filled in by the domain builder for the HVM guest to
> function.  It would be cleaner for the domain builder to also allocate
> an adjacent page for the VM86_TSS when it constructs the IDENT_PT.

I'll leave that for someone else to carry out; for now allocation
will remain in hvmloader.

> Finally, the IO bitmap needs to be a fraction larger than 160 bytes.
> 
> From tools/firmware/rombios/rombios.h:
> 
> #define PANIC_PORT  0x400
> #define PANIC_PORT2 0x401
> #define INFO_PORT   0x402
> #define DEBUG_PORT  0x403
> 
> which are just above the ISA range.

Which causes only slowness (due to needing the emulator to carry
out the instruction), but no lack of functionality.

>  I'd also just allocate a full page
> for it; no OS is going to bother trying to use fractions of a page
> around an E820 reserved region.

But the smaller range may well be part of an already partially used
page. Together with the fact that any port accesses not covered
by the bitmap would still be correctly handled, I'd prefer to make
the TSS 0x68 + 0x20 + 0x80 + 1 bytes large (base structure plus
interrupt redirection bitmap plus I/O bitmap plus trailing byte),
which, due to the goal of avoiding page boundaries in the middle,
would mean a 512 byte block aligned to a 512-byte boundary.

Jan


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