[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map
At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote: > >>> On 27.01.17 at 14:20, <tim@xxxxxxx> wrote: > > At 12:51 +0000 on 27 Jan (1485521470), Andrew Cooper wrote: > >> On 27/01/17 11:14, Tim Deegan wrote: > >> > But looking at it now, I'm not convinced of exactly how. The magic > >> > bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map > >> > base address itself lives at offset 100. A zero'd TSS should mean an > >> > I/O map at 0, and an interrupt redirection bitmap at -32, which would > >> > plausibly work if the TSS were 256 bytes (matching the limit set in > >> > Xen). Perhaps it's only working because the 128 bytes following the > >> > TSS in hvmloader happen to be zeros too? > >> > >> With an IO_base_map of 0, the software interrupt bitmap will end up > >> being ahead of the TSS, not after it. > > > > I should have thought that the segmented address calculation would > > wrap and leave us at TSS + 224. > > I don't think wrapping takes the limit value into account. Quite right, I'm talking nonsense. > - vmx_set_segment_register() will need to set a correct limit Yep. > - vmx_set_segment_register() should initialize the TSS every > time (including setting the I/O bitmap address to no lower > than 32) Probably to no lower than 136, to avoid having the bits of that field itself appearing in either the IO or interrupt bitmap. > - 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 think Andrew's suggestion of just using a whole page is a good one. The TSS is a 32-bit one, after all, and doesn't need to live in BIOS space. Cheers, Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |