Andy Lutomirski writes:
> On 04/20/2015 10:09 AM, Andrew Cooper wrote:
>> There appears to be no formal statement of what pv_irq_ops.save_fl() is
>> supposed to return precisely. Native returns the full flags, while lguest
>> and
>> Xen only return the Interrupt Flag, and both have comments by t
>>> On 20.04.15 at 19:09, wrote:
> A different approach, given the dual nature of the AC flag now is to gate
> setup_smap() on a kernel rpl of 0. SMAP necessarily can't be used in a
> paravirtual situation where the kernel runs in cpl > 0.
"Can't" isn't true here - for 64-bit PV Xen guests, whic
On 21/04/2015 01:35, Andy Lutomirski wrote:
> On 04/20/2015 10:09 AM, Andrew Cooper wrote:
>> There appears to be no formal statement of what pv_irq_ops.save_fl() is
>> supposed to return precisely. Native returns the full flags, while
>> lguest and
>> Xen only return the Interrupt Flag, and both
On 04/20/2015 10:09 AM, Andrew Cooper wrote:
There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely. Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only t
On 20/04/15 18:09, Andrew Cooper wrote:
> There appears to be no formal statement of what pv_irq_ops.save_fl() is
> supposed to return precisely. Native returns the full flags, while lguest and
> Xen only return the Interrupt Flag, and both have comments by the
> implementations stating that only
There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely. Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at. This may
have
6 matches
Mail list logo
