On 10/09/18 14:59, Jan Beulich wrote:
> For one it is quite pointless to iterate over all pIRQ-s the domain has
> when just one is being adjusted. Introduce hvm_migrate_pirq().
>
> Additionally it is bogus to migrate the pIRQ to a vCPU different from
> the one the event is supposed to be posted to
On Mon, Sep 10, 2018 at 07:59:16AM -0600, Jan Beulich wrote:
> For one it is quite pointless to iterate over all pIRQ-s the domain has
> when just one is being adjusted. Introduce hvm_migrate_pirq().
>
> Additionally it is bogus to migrate the pIRQ to a vCPU different from
> the one the event is s
>>> On 13.09.18 at 07:56, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 10, 2018 9:59 PM
>>
>> For one it is quite pointless to iterate over all pIRQ-s the domain has
>> when just one is being adjusted. Introduce hvm_migrate_pirq().
>
> it's migrate_pirq bein
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 10, 2018 9:59 PM
>
> For one it is quite pointless to iterate over all pIRQ-s the domain has
> when just one is being adjusted. Introduce hvm_migrate_pirq().
it's migrate_pirq being introduced here.
>
> Additionally it is
For one it is quite pointless to iterate over all pIRQ-s the domain has
when just one is being adjusted. Introduce hvm_migrate_pirq().
Additionally it is bogus to migrate the pIRQ to a vCPU different from
the one the event is supposed to be posted to - if anything, it might be
worth considering no
