On 2015/10/3 16:20, Feng Wu wrote:
> irq_set_vcpu_affinity() is needed when CONFIG_SMP=n, so move the
> definition out of "#ifdef CONFIG_SMP"
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Feng Wu
Reviewed-by: Jiang Liu
> ---
On 2015/7/10 15:52, Marc Zyngier wrote:
> On 09/07/15 22:33, Thomas Gleixner wrote:
>> On Thu, 9 Jul 2015, Marc Zyngier wrote:
>>
>>> When used as a primary interrupt controller, the GIC driver uses
>>> irq_data->chip_data to extract controller-specific information.
>>>
>>> When used as a secondary
On 2014/12/24 10:32, Zhang, Yang Z wrote:
> Jiang Liu wrote on 2014-12-24:
>> On 2014/12/24 9:38, Zhang, Yang Z wrote:
>>> Paolo Bonzini wrote on 2014-12-23:
>>>>
>>>>
>>>> On 23/12/2014 10:07, Wu, Feng wrote:
>>>>>> On 23/12/
On 2014/12/24 9:38, Zhang, Yang Z wrote:
> Paolo Bonzini wrote on 2014-12-23:
>>
>>
>> On 23/12/2014 10:07, Wu, Feng wrote:
On 23/12/2014 01:37, Zhang, Yang Z wrote:
> I don't quite understand it. If user set an interrupt's affinity
> to a CPU, but he still see the interrupt delivers t
.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html
Signed-off-by: Jiang Liu
Signed-off-by: Feng Wu
---
include/linux/irq.h |6 ++
kernel/irq/manage.c | 19 +++
2 files changed, 25 insertions(+)
diff --git a/include/linux/irq.h b/include
On 2014/11/20 12:53, Wu, Feng wrote:
>
>
>> -Original Message-
>>> + /*
>>> +* Initialize Posted-Interrupt Descriptor
>>> +*/
>>> +
>>> + pi_clear_sn(&vmx->pi_desc);
>>> + vmx->pi_desc.nv = POSTED_INTR_VECTOR;
>>> +
>>> + /* Physical mode for Notificaiton Event */
>>> +
On 2014/11/10 14:26, Feng Wu wrote:
> We don't need to migrate the irqs for VT-d Posted-Interrtups here.
> When 'pst' is set in IRTE, the associated irq will be posted to
> guests instead of interrupt remapping. The destination of the
> interrupt is set in Posted-Interrupts Descriptor, and the mi
Hi Feng,
Other than this solution, how about introducing new
struct irte_pi for posted interrupt?
On 2014/11/10 14:26, Feng Wu wrote:
> This patch adjusts the definition of 'struct irte', so that we can
> add the VT-d Posted-Interrtups format in this structure later.
>
> Signed-off-by: Fe
On 2014/11/10 14:26, Feng Wu wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
>
>
On 2014/11/10 14:26, Feng Wu wrote:
> This patch initialize the VT-d Posted-interrupt Descritpor.
>
> Signed-off-by: Feng Wu
> ---
> arch/x86/include/asm/irq_remapping.h |1 +
> arch/x86/kernel/apic/apic.c |1 +
> arch/x86/kvm/vmx.c | 56 +
On 2014/11/11 2:15, Thomas Gleixner wrote:
> On Mon, 10 Nov 2014, Feng Wu wrote:
>
>> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
>> With VT-d Posted-Interrupts enabled, external interrupts from
>> direct-assigned devices can be delivered to guests without VMM
>> interve
Hi Alex and Joerg,
I have my travel request approved but missed the registration window.
Hope I will be lucky:)
Regards!
Gerry
On 2014/8/21 1:10, Alex Williamson wrote:
>
> Ok folks, it's time to submit your discussion proposals for the LPC
> IOMMU and VFIO uconf. If you added an idea to
/current cpu.
If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id()
is the same as cpu_to_node()/numa_node_id().
Signed-off-by: Jiang Liu
---
arch/x86/kvm/vmx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
On error recovery path in function vfio_create_group(), it should
unregister the IOMMU notifier for the new VFIO group. Otherwise it may
cause invalid memory access later when handling bus notifications.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c | 31 +++
1
Comments from dev_driver_string(),
/* dev->driver can change to NULL underneath us because of unbinding,
* so be careful about accessing it.
*/
So use ACCESS_ONCE() to guard access to dev->driver field.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c |3 ++-
1 file changed, 2 inse
The two labels for error recovery in function vfio_pci_init() is out of
order, so fix it.
Signed-off-by: Jiang Liu
---
drivers/vfio/pci/vfio_pci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 6968b72
On 11/11/2012 01:21 PM, Greg Kroah-Hartman wrote:
> On Sat, Nov 10, 2012 at 09:57:14PM +0800, Jiang Liu wrote:
>> From: Jiang Liu
>>
>> There are several requirements to temporarily reject device driver
>> binding. Possible usage cases as below:
>> 1) We should
From: Jiang Liu
Comments from dev_driver_string(),
/* dev->driver can change to NULL underneath us because of unbinding,
* so be careful about accessing it.
*/
So use ACCESS_ONCE() to guard access to dev->driver field.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c |3 ++-
From: Jiang Liu
Now we have a way to reject binding unsafe drivers to devices belonging
to active VFIO groups, so we could simplify IOMMU group notification
handler to only handle IOMMU_GROUP_NOTIFY_SOLICIT_BINDING event.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c | 90
From: Jiang Liu
VFIO driver should reject binding unsafe drivers to devices belonging to
active VFIO groups, otherwise it will break the DMA isolation property
of VFIO groups. So hook IOMMU_GROUP_NOTIFY_QUERY_BINDING event to reject
unsafe device driver binding for active VFIO groups.
Signed
From: Jiang Liu
On error recovery path in function vfio_create_group(), it should
unregister the IOMMU notifier for the new VFIO group. Otherwise it may
cause invalid memory access later when handling bus notifications.
Signed-off-by: Jiang Liu
---
drivers/vfio/vfio.c | 31
From: Jiang Liu
Pass on BUS_NOTIFY_QUERY_BINDING event to iommu group notifier clients,
so notifier clients have a chance to reject device driver binding.
Signed-off-by: Jiang Liu
---
drivers/iommu/iommu.c | 14 +-
include/linux/iommu.h |1 +
2 files changed, 10 insertions
From: Jiang Liu
There are several requirements to temporarily reject device driver
binding. Possible usage cases as below:
1) We should avoid binding an unsafe driver to a device belonging to
an active VFIO group, otherwise it will break the DMA isolation
property of VFIO.
2) When hot
23 matches
Mail list logo
