Re: [Xen-devel] [PATCH v7 2/7] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Thu, Feb 23, 2017 at 06:39:53AM -0700, Jan Beulich wrote:
> >>> On 22.02.17 at 15:24, <roger.pau@xxxxxxxxxx> wrote:
> > Craft the Dom0 e820 memory map and populate it. Introduce a helper to remove
> > memory pages that are shared between Xen and a domain, and use it in order 
> > to
> > remove low 1MB RAM regions from dom_io in order to assign them to a PVHv2 
> > Dom0.
> > 
> > On hardware lacking support for unrestricted mode also craft the identity 
> > page
> > tables and the TSS used for virtual 8086 mode.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> albeit ...
> 
> > @@ -44,6 +45,16 @@ static long __initdata dom0_min_nrpages;
> >  static long __initdata dom0_max_nrpages = LONG_MAX;
> >  
> >  /*
> > + * Have the TSS cover the ISA port range, which makes it
> > + * - 104 bytes base structure
> > + * - 32 bytes interrupt redirection bitmap
> > + * - 128 bytes I/O bitmap
> > + * - one trailing byte
> > + * or a total of 265 bytes.
> > + */
> > +#define HVM_VM86_TSS_SIZE 265
> 
> ... I'm not convinced the same rationale as used in hvmloader
> applies here. Namely, the more without legacy devices, there
> should be pretty little reason for such a Dom0 to do port I/O
> to any (including the ISA) ports from real mode, nor can I see
> the usefulness of invoking INT $n instructions without there
> being any firmware.

Right, without firmware there isn't much point in any of this. This is just
going to be used to boot the APs, and that's probably all (which shouldn't
attempt to write to any IO port or execute any INT instruction).

I also don't see much benefit from deviating from what HVM does, so I would
just leave it as is.

Thanks, Roger.

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