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

>>> On 27.01.17 at 19:06, 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

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

>>> On 27.01.17 at 20:48, wrote: > At 09:40 -0700 on 27 Jan (1485510008), Jan Beulich wrote: >> - 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

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

On 30/01/17 10:43, Jan Beulich wrote: On 27.01.17 at 20:43, wrote: >>> Despite being owned by the guest, this TSS is actually managed by >> Xen. >>> It should be initialised to defaults each time Xen needs to use it >> on >>> behalf of the guest. >> At 14:35 + on 27 Jan

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

>>> On 27.01.17 at 20:43, wrote: >> Despite being owned by the guest, this TSS is actually managed by > Xen. >> It should be initialised to defaults each time Xen needs to use it > on >> behalf of the guest. > > At 14:35 + on 27 Jan (1485527708), Andrew Cooper wrote: >> On

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, wrote: > > At 12:51 + 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 > >> >

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

> Despite being owned by the guest, this TSS is actually managed by Xen. > It should be initialised to defaults each time Xen needs to use it on > behalf of the guest. At 14:35 + on 27 Jan (1485527708), Andrew Cooper wrote: > On 27/01/17 14:01, Tim Deegan wrote: > > Hi, > > > > At 13:46

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

On 27/01/17 16:40, Jan Beulich wrote: On 27.01.17 at 14:20, wrote: >> At 12:51 + 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

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

>>> On 27.01.17 at 14:20, wrote: > At 12:51 + 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

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

>>> On 27.01.17 at 17:04, wrote: > On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote: >> >>> On 27.01.17 at 13:23, wrote: >> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote: >> >> >>> On 19.01.17 at 18:29,

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

On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote: > >>> On 27.01.17 at 13:23, wrote: > > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote: > >> >>> On 19.01.17 at 18:29, wrote: > >> > @@ -43,6 +44,9 @@ static long __initdata

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

>>> On 27.01.17 at 13:23, wrote: > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote: >> >>> On 19.01.17 at 18:29, wrote: >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages; >> > static long __initdata dom0_min_nrpages; >> > static

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

On 27/01/17 14:01, Tim Deegan wrote: > Hi, > > At 13:46 + on 27 Jan (1485524765), Andrew Cooper wrote: >> The actual behaviour can be determined by putting the TSS on a page >> boundary, making the previous frame non-readable via EPT, and seeing >> whether an EPT violation occurs. > Indeed.

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

Hi, At 13:46 + on 27 Jan (1485524765), Andrew Cooper wrote: > The actual behaviour can be determined by putting the TSS on a page > boundary, making the previous frame non-readable via EPT, and seeing > whether an EPT violation occurs. Indeed. Or likewise with normal pagetables. > > Yes,

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

On 27/01/17 13:20, Tim Deegan wrote: > Hi, > > At 12:51 + 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 >>>

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

Hi, At 12:51 + 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

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

On 27/01/17 11:14, Tim Deegan wrote: > At 05:41 -0700 on 26 Jan (1485409318), Jan Beulich wrote: > On 19.01.17 at 18:29, wrote: >>> +/* Size of the VM86 TSS for virtual 8086 mode to use. */ >>> +#define HVM_VM86_TSS_SIZE 128 >> I continue to be puzzled by this value.

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

On Fri, Jan 27, 2017 at 11:14:10AM +, Tim Deegan wrote: > At 05:41 -0700 on 26 Jan (1485409318), Jan Beulich wrote: > > >>> On 19.01.17 at 18:29, wrote: > > > +/* Size of the VM86 TSS for virtual 8086 mode to use. */ > > > +#define HVM_VM86_TSS_SIZE 128 > > > > I

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

On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote: > >>> On 19.01.17 at 18:29, wrote: > > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages; > > static long __initdata dom0_min_nrpages; > > static long __initdata dom0_max_nrpages = LONG_MAX; > > > > +/*

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

At 05:41 -0700 on 26 Jan (1485409318), Jan Beulich wrote: > >>> On 19.01.17 at 18:29, wrote: > > +/* Size of the VM86 TSS for virtual 8086 mode to use. */ > > +#define HVM_VM86_TSS_SIZE 128 > > I continue to be puzzled by this value. Why 128? I think this really > needs

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

>>> On 19.01.17 at 18:29, wrote: > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages; > static long __initdata dom0_min_nrpages; > static long __initdata dom0_max_nrpages = LONG_MAX; > > +/* Size of the VM86 TSS for virtual 8086 mode to use. */ > +#define

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

On Mon, Jan 23, 2017 at 09:11:06AM -0500, Boris Ostrovsky wrote: > > > > > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn, > > + unsigned long nr_pages, bool map) > > +{ > > +int rc; > > + > > +for ( ; ; ) > > +{ > >

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

> > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn, > + unsigned long nr_pages, bool map) > +{ > +int rc; > + > +for ( ; ; ) > +{ > +rc = (map ? map_mmio_regions : unmap_mmio_regions) This can be taken

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

>>> On 20.01.17 at 20:41, wrote: > On 19/01/17 17:29, Roger Pau Monne wrote: >> +tss = map_domain_gfn(p2m_get_hostp2m(d), _gfn(PFN_DOWN(gaddr)), >> + , , 0, ); >> +if ( tss == NULL ) >> +{ >> +printk("Unable to map VM86 TSS

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

On 19/01/17 17:29, Roger Pau Monne wrote: > +static int __init pvh_setup_vmx_realmode_helpers(struct domain *d) > +{ > +p2m_type_t p2mt; > +uint32_t rc, *ident_pt; > +uint8_t *tss; > +mfn_t mfn; > +paddr_t gaddr; > +unsigned int i; > + > +/* > + * Steal some space

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

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. Signed-off-by: Roger Pau Monné --- Cc: