On 20/11/2019 15:49, Jürgen Groß wrote:
> On 15.11.19 19:59, Igor Druzhinin wrote:
>> From: Paul Durrant
>>
>> Dropping the pcidevs lock between calling device_assigned() and
>> assign_device() means that the latter has to do the same check as the
>> former for no obvious gain. Also, since long ru
On 15.11.19 19:59, Igor Druzhinin wrote:
From: Paul Durrant
Dropping the pcidevs lock between calling device_assigned() and
assign_device() means that the latter has to do the same check as the
former for no obvious gain. Also, since long running operations under
pcidevs lock already drop the l
On 18/11/2019 11:21, Jan Beulich wrote:
> On 15.11.2019 19:59, Igor Druzhinin wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -932,30 +932,26 @@ static int deassign_device(struct domain *d, uint16_t
>> seg, uint8_t bus,
>> break;
>>
On 15.11.2019 19:59, Igor Druzhinin wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -932,30 +932,26 @@ static int deassign_device(struct domain *d, uint16_t
> seg, uint8_t bus,
> break;
> ret = hd->platform_ops->reassign_device(d, targe
From: Paul Durrant
Dropping the pcidevs lock between calling device_assigned() and
assign_device() means that the latter has to do the same check as the
former for no obvious gain. Also, since long running operations under
pcidevs lock already drop the lock and return -ERESTART periodically there
