[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54941326.4080405@redhat.com>
Date: Fri, 19 Dec 2014 12:59:34 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Yang Zhang <yang.z.zhang@...el.com>,
"Wu, Feng" <feng.wu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, Gleb Natapov <gleb@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"joro@...tes.org" <joro@...tes.org>,
Alex Williamson <alex.williamson@...hat.com>,
Jiang Liu <jiang.liu@...ux.intel.com>
CC: "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
KVM list <kvm@...r.kernel.org>,
Eric Auger <eric.auger@...aro.org>
Subject: Re: [v3 06/26] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts
On 19/12/2014 02:46, Zhang, Yang Z wrote:
>> If the IRQ is posted, its affinity is controlled by guest (irq <--->
>> vCPU <----> pCPU), it has no effect when host changes its affinity.
>
> That's the problem: User is able to changes it in host but it never
> takes effect since it is actually controlled by guest. I guess it
> will break the IRQ balance too.
I don't think that's a problem.
Controlling the affinity in the host affects which CPU in the host takes
care of signaling the guest.
If this signaling is done directly by the chipset, there is no need to
do anything in the host and thus the host affinity can be bypassed.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists