>>> On 27.01.17 at 19:06, <andrew.coop...@citrix.com> 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@lists.xen.org https://lists.xen.org/xen-devel
