>>> On 22.02.17 at 11:45, wrote:
> On 17/02/17 12:03, Jan Beulich wrote:
>> @@ -4267,6 +4336,12 @@ static int hvmop_get_param(
>> case HVM_PARAM_ACPI_S_STATE:
>> a.value = d->arch.hvm_domain.is_s3_suspended ? 3 : 0;
>> break;
>> +
>> +case HVM_PARAM_VM86_TSS:
>> +
On 17/02/17 12:03, Jan Beulich wrote:
> @@ -4267,6 +4336,12 @@ static int hvmop_get_param(
> case HVM_PARAM_ACPI_S_STATE:
> a.value = d->arch.hvm_domain.is_s3_suspended ? 3 : 0;
> break;
> +
> +case HVM_PARAM_VM86_TSS:
> +a.value = (uint32_t)d->arch.hvm_domain.par
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, February 17, 2017 8:04 PM
>
> The present way of setting this up is flawed: Leaving the I/O bitmap
> pointer at zero means that the interrupt redirection bitmap lives
> outside (ahead of) the allocated space of the TSS. Similarly setti
At 04:17 -0700 on 20 Feb (1487564245), Jan Beulich wrote:
> >>> On 20.02.17 at 12:01, wrote:
> > At 05:03 -0700 on 17 Feb (1487307837), Jan Beulich wrote:
> >> The present way of setting this up is flawed: Leaving the I/O bitmap
> >> pointer at zero means that the interrupt redirection bitmap live
>>> On 20.02.17 at 12:01, wrote:
> At 05:03 -0700 on 17 Feb (1487307837), Jan Beulich wrote:
>> The present way of setting this up is flawed: Leaving the I/O bitmap
>> pointer at zero means that the interrupt redirection bitmap lives
>> outside (ahead of) the allocated space of the TSS. Similarly
At 05:03 -0700 on 17 Feb (1487307837), Jan Beulich wrote:
> The present way of setting this up is flawed: Leaving the I/O bitmap
> pointer at zero means that the interrupt redirection bitmap lives
> outside (ahead of) the allocated space of the TSS. Similarly setting a
> TSS limit of 255 when only
The present way of setting this up is flawed: Leaving the I/O bitmap
pointer at zero means that the interrupt redirection bitmap lives
outside (ahead of) the allocated space of the TSS. Similarly setting a
TSS limit of 255 when only 128 bytes get allocated means that 128 extra
bytes may be accessed
