On Wed, Oct 09, 2019 at 07:13:45PM +0800, Chao Gao wrote:
> On Wed, Oct 09, 2019 at 10:33:21AM +0200, Roger Pau Monne wrote:
> >The current implementation of host_maskall makes it sticky across
> >assign and deassign calls, which means that once a guest forces Xen to
> >set host_maskall the maskall
On 09.10.19 11:49, Jan Beulich wrote:
On 09.10.2019 10:33, Roger Pau Monne wrote:
The current implementation of host_maskall makes it sticky across
assign and deassign calls, which means that once a guest forces Xen to
set host_maskall the maskall bit is not going to be cleared until a
call to P
On Wed, Oct 09, 2019 at 10:33:21AM +0200, Roger Pau Monne wrote:
>The current implementation of host_maskall makes it sticky across
>assign and deassign calls, which means that once a guest forces Xen to
>set host_maskall the maskall bit is not going to be cleared until a
>call to PHYSDEVOP_prepare
On 09.10.2019 10:33, Roger Pau Monne wrote:
> The current implementation of host_maskall makes it sticky across
> assign and deassign calls, which means that once a guest forces Xen to
> set host_maskall the maskall bit is not going to be cleared until a
> call to PHYSDEVOP_prepare_msix is performe
The current implementation of host_maskall makes it sticky across
assign and deassign calls, which means that once a guest forces Xen to
set host_maskall the maskall bit is not going to be cleared until a
call to PHYSDEVOP_prepare_msix is performed. Such call however
shouldn't be part of the normal
