On Mon, 14 Dec 2015, Jan Beulich wrote:
> >>> On 11.12.15 at 17:56, wrote:
> > For the original issue here, could the flag be exposed as a
> > XEN_SYSCTL_PHYSCAP_
>
> Yes, I think it could, albeit calling this a "capability" or "feature"
> seems odd (since really the original behavior was bog
>>> On 11.12.15 at 17:56, wrote:
> For the original issue here, could the flag be exposed as a
> XEN_SYSCTL_PHYSCAP_
Yes, I think it could, albeit calling this a "capability" or "feature"
seems odd (since really the original behavior was bogus/buggy).
But - with sysctl not being a stable inte
On Mon, 2015-12-14 at 11:19 +, Stefano Stabellini wrote:
> On Fri, 11 Dec 2015, Ian Campbell wrote:
> > On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> > >
> > > It is not possible to do this at runtime. I think we should do this
> > > at
> > > compile time because in any case
On Mon, 14 Dec 2015, Jan Beulich wrote:
> >>> On 11.12.15 at 17:56, wrote:
> > On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> >>
> >> It is not possible to do this at runtime. I think we should do this at
> >> compile time because in any case it is not supported to run a QEMU bui
On Fri, 11 Dec 2015, Ian Campbell wrote:
> On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> >
> > It is not possible to do this at runtime. I think we should do this at
> > compile time because in any case it is not supported to run a QEMU built
> > for a given Xen version on a diff
>>> On 11.12.15 at 17:56, wrote:
> On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
>>
>> It is not possible to do this at runtime. I think we should do this at
>> compile time because in any case it is not supported to run a QEMU built
>> for a given Xen version on a different Xen v
On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
>
> It is not possible to do this at runtime. I think we should do this at
> compile time because in any case it is not supported to run a QEMU built
> for a given Xen version on a different Xen version.
I am currently working pretty h
On Fri, 11 Dec 2015, Jan Beulich wrote:
> >>> On 11.12.15 at 15:33, wrote:
> > On Mon, 7 Dec 2015, Jan Beulich wrote:
> >> >>> On 07.12.15 at 15:56, wrote:
> >> > On Mon, 7 Dec 2015, Jan Beulich wrote:
> >> >> >>> On 07.12.15 at 13:45, wrote:
> >> >> > On Tue, 24 Nov 2015, Jan Beulich wrote:
> >
>>> On 11.12.15 at 15:33, wrote:
> On Mon, 7 Dec 2015, Jan Beulich wrote:
>> >>> On 07.12.15 at 15:56, wrote:
>> > On Mon, 7 Dec 2015, Jan Beulich wrote:
>> >> >>> On 07.12.15 at 13:45, wrote:
>> >> > On Tue, 24 Nov 2015, Jan Beulich wrote:
>> >> >> TBD: We probably need to deal with running on
On Mon, 7 Dec 2015, Jan Beulich wrote:
> >>> On 07.12.15 at 15:56, wrote:
> > On Mon, 7 Dec 2015, Jan Beulich wrote:
> >> >>> On 07.12.15 at 13:45, wrote:
> >> > On Tue, 24 Nov 2015, Jan Beulich wrote:
> >> >> Now that the hypervisor intercepts all config space writes and monitors
> >> >> changes
>>> On 07.12.15 at 15:56, wrote:
> On Mon, 7 Dec 2015, Jan Beulich wrote:
>> >>> On 07.12.15 at 13:45, wrote:
>> > On Tue, 24 Nov 2015, Jan Beulich wrote:
>> >> Now that the hypervisor intercepts all config space writes and monitors
>> >> changes to the masking flags, this undoes the main effect
On Mon, 7 Dec 2015, Jan Beulich wrote:
> >>> On 07.12.15 at 13:45, wrote:
> > On Tue, 24 Nov 2015, Jan Beulich wrote:
> >> Now that the hypervisor intercepts all config space writes and monitors
> >> changes to the masking flags, this undoes the main effect of the
> >> XSA-129 fix, exposing the ma
>>> On 07.12.15 at 13:45, wrote:
> On Tue, 24 Nov 2015, Jan Beulich wrote:
>> Now that the hypervisor intercepts all config space writes and monitors
>> changes to the masking flags, this undoes the main effect of the
>> XSA-129 fix, exposing the masking capability again to guests.
>>
>> Signed-o
On Tue, 24 Nov 2015, Jan Beulich wrote:
> Now that the hypervisor intercepts all config space writes and monitors
> changes to the masking flags, this undoes the main effect of the
> XSA-129 fix, exposing the masking capability again to guests.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: We proba
Now that the hypervisor intercepts all config space writes and monitors
changes to the masking flags, this undoes the main effect of the
XSA-129 fix, exposing the masking capability again to guests.
Signed-off-by: Jan Beulich
---
TBD: We probably need to deal with running on an older hypervisor.
15 matches
Mail list logo