>>> 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 initialize the TSS every
>> time
>>> 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 having the bits of
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 (1485527708), Andr
>>> 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 27/01/17 14:01, Ti
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
> >> > bitmap in the TSS
> 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 +
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 Map Base Addres
>>> 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
>> > base addres
>>> 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, wrote:
>> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpag
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 dom0_nrpages;
> >> > static long __initdata dom0_
>>> 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 long __initdata dom0_max_nrpages = LONG_MAX;
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. Or
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, I
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
>>> bas
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 ze
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. Why 128? I think this re
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 continue to be puzzled by t
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;
> >
> > +/* Size of the VM86 TSS for v
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 to be clarified in the c
>>> 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 HVM_VM86_TSS_SIZE 128
I continu
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 ( ; ; )
> > +{
> >
>
> +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 outsid
>>> 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)),
>> + &mfn, &p2mt, 0, &rc);
>> +if ( tss == NULL )
>> +{
>> +printk("Unable to map VM86 TSS area\n");
>> +
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 fr
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: Jan Beulich
Cc: Andrew
25 matches
Mail list logo
