On 08.10.2019 16:16, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 03:32:25PM +0200, Jan Beulich wrote:
>> On 08.10.2019 15:14, Roger Pau Monné wrote:
>>> On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
On 08.10.2019 13:09, Roger Pau Monné wrote:
> Given that as you corr
On Tue, Oct 08, 2019 at 03:32:25PM +0200, Jan Beulich wrote:
> On 08.10.2019 15:14, Roger Pau Monné wrote:
> > On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
> >> On 08.10.2019 13:09, Roger Pau Monné wrote:
> >>> Given that as you correctly point out maskall is unset after device
>
On 08.10.2019 15:14, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
>> On 08.10.2019 13:09, Roger Pau Monné wrote:
>>> Given that as you correctly point out maskall is unset after device
>>> reset, I feel that option 4 is the best one since it matches the st
On Tue, Oct 08, 2019 at 01:28:49PM +0200, Jan Beulich wrote:
> On 08.10.2019 13:09, Roger Pau Monné wrote:
> > Given that as you correctly point out maskall is unset after device
> > reset, I feel that option 4 is the best one since it matches the state
> > of the hardware after reset.
>
> Right,
On 08.10.2019 13:09, Roger Pau Monné wrote:
> On Tue, Oct 08, 2019 at 11:42:23AM +0200, Jan Beulich wrote:
>> On 08.10.2019 11:23, Roger Pau Monné wrote:
>>> On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
On 02.10.2019 12:49, Roger Pau Monne wrote:
> The current implementat
On Tue, Oct 08, 2019 at 11:42:23AM +0200, Jan Beulich wrote:
> On 08.10.2019 11:23, Roger Pau Monné wrote:
> > On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
> >> On 02.10.2019 12:49, Roger Pau Monne wrote:
> >>> The current implementation of host_maskall makes it sticky across
> >>>
On 08.10.2019 11:23, Roger Pau Monné wrote:
> On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
>> On 02.10.2019 12:49, 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
On Wed, Oct 02, 2019 at 03:33:43PM +0200, Jan Beulich wrote:
> On 02.10.2019 12:49, 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 goi
On Mon, Oct 07, 2019 at 09:38:48AM +0200, Jan Beulich wrote:
>On 05.10.2019 01:58, Chao Gao wrote:
>> On Wed, Oct 02, 2019 at 12:49:35PM +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 f
On 05.10.2019 01:58, Chao Gao wrote:
> On Wed, Oct 02, 2019 at 12:49:35PM +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
On Wed, Oct 02, 2019 at 12:49:35PM +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 02.10.2019 12:49, 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
13 matches
Mail list logo
