On 11/24/2016 9:37 PM, Edgar E. Iglesias wrote:
On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
Hi,
I have a few questions.
If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
So guests will essentially create int
On November 24, 2016 9:38 PM,
>On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
>> On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
>> Hi,
>> > > >
>> > > > I have a few questions.
>> > > >
>> > > > If I understand correctly, you'll be emulating an Intel IOMMU in
On Thu, Nov 24, 2016 at 02:49:41PM +0800, Lan Tianyu wrote:
> On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
> Hi,
> > > >
> > > > I have a few questions.
> > > >
> > > > If I understand correctly, you'll be emulating an Intel IOMMU in
> > > > Xen.
> > > > So gue
On 2016年11月24日 12:09, Edgar E. Iglesias wrote:
Hi,
> > >
> > > I have a few questions.
> > >
> > > If I understand correctly, you'll be emulating an Intel IOMMU in Xen.
> > > So guests will essentially create intel iommu style page-tables.
> > >
> > > If we w
On Thu, Nov 24, 2016 at 02:00:21AM +, Tian, Kevin wrote:
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: Thursday, November 24, 2016 3:09 AM
> >
> > On Wed, 23 Nov 2016, Edgar E. Iglesias wrote:
> > > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> > > > H
On 2016年11月22日 18:24, Jan Beulich wrote:
On 17.11.16 at 16:36, wrote:
>> 2) Build ACPI DMAR table in toolstack
>> Now tool stack can boot ACPI DMAR table according VM configure and pass
>> though it to hvmloader via xenstore ACPI PT channel. But the vIOMMU MMIO
>> region is managed by Qemu an
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: Thursday, November 24, 2016 3:09 AM
>
> On Wed, 23 Nov 2016, Edgar E. Iglesias wrote:
> > On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> > > Hi All:
> > > The following is our Xen vIOMMU high level design for d
On Wed, 23 Nov 2016, Edgar E. Iglesias wrote:
> On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> > Hi All:
> > The following is our Xen vIOMMU high level design for detail
> > discussion. Please have a look. Very appreciate for your comments.
> > This design doesn't cover changes
On Wed, Aug 17, 2016 at 08:05:51PM +0800, Lan, Tianyu wrote:
> Hi All:
> The following is our Xen vIOMMU high level design for detail
> discussion. Please have a look. Very appreciate for your comments.
> This design doesn't cover changes when root port is moved to hypervisor.
> We may design
On 2016年11月21日 15:05, Tian, Kevin wrote:
>> If someone add "intel_iommu=on" kernel parameter manually, IOMMU driver
>> > will panic guest because it can't enable DMA remapping function via gcmd
>> > register and "Translation Enable Status" bit in gsts register is never
>> > set by vIOMMU. This show
>>> On 17.11.16 at 16:36, wrote:
> 2) Build ACPI DMAR table in toolstack
> Now tool stack can boot ACPI DMAR table according VM configure and pass
> though it to hvmloader via xenstore ACPI PT channel. But the vIOMMU MMIO
> region is managed by Qemu and it's need to be populated into DMAR
> table.
On 2016年11月21日 21:41, Andrew Cooper wrote:
> On 17/11/16 15:36, Lan Tianyu wrote:
>> 3.2 l2 translation
>> 1) For virtual PCI device
>> Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
>> hypercall when DMA operation happens.
>>
>> When guest triggers a invalidation operation, the
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, November 21, 2016 9:41 PM
>
> On 17/11/16 15:36, Lan Tianyu wrote:
> > 3.2 l2 translation
> > 1) For virtual PCI device
> > Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
> > hypercall when DMA operation h
On Mon, 21 Nov 2016, Julien Grall wrote:
> On 21/11/2016 02:21, Lan, Tianyu wrote:
> > On 11/19/2016 3:43 AM, Julien Grall wrote:
> > > On 17/11/2016 09:36, Lan Tianyu wrote:
> > Hi Julien:
>
> Hello Lan,
>
> > Thanks for your input. This interface is just for virtual PCI device
> > which is
On 17/11/16 15:36, Lan Tianyu wrote:
> 3.2 l2 translation
> 1) For virtual PCI device
> Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
> hypercall when DMA operation happens.
>
> When guest triggers a invalidation operation, there maybe in-fly DMA
> request for virtual device ha
On 21/11/2016 02:21, Lan, Tianyu wrote:
On 11/19/2016 3:43 AM, Julien Grall wrote:
On 17/11/2016 09:36, Lan Tianyu wrote:
Hi Julien:
Hello Lan,
Thanks for your input. This interface is just for virtual PCI device
which is called by Qemu. I am not familiar with ARM. Are there any
non-P
> From: Lan, Tianyu
> Sent: Thursday, November 17, 2016 11:37 PM
>
> Change since V2:
> 1) Update motivation for Xen vIOMMU - 288 vcpus support part
> Add descriptor about plan of increasing vcpu from 128 to 255 and
> dependency between X2APIC and interrupt remapping.
> 2) Update
On 11/19/2016 3:43 AM, Julien Grall wrote:
Hi Lan,
On 17/11/2016 09:36, Lan Tianyu wrote:
1) Definition of "struct xen_dmop_viommu_op" as new hypercall parameter.
struct xen_dmop_viommu_op {
u32 cmd;
u32 domid;
u32 viommu_id;
union {
struct {
u32 capabili
Hi Lan,
On 17/11/2016 09:36, Lan Tianyu wrote:
1) Definition of "struct xen_dmop_viommu_op" as new hypercall parameter.
struct xen_dmop_viommu_op {
u32 cmd;
u32 domid;
u32 viommu_id;
union {
struct {
u32 capabilities;
} query_capabilities;
st
Change since V2:
1) Update motivation for Xen vIOMMU - 288 vcpus support part
Add descriptor about plan of increasing vcpu from 128 to 255 and
dependency between X2APIC and interrupt remapping.
2) Update 3.1 New vIOMMU hypercall interface
Change vIOMMU hypercall fro
On 10/26/2016 5:39 PM, Jan Beulich wrote:
On 22.10.16 at 09:32, wrote:
On 10/21/2016 4:36 AM, Andrew Cooper wrote:
3.5 Implementation consideration
VT-d spec doesn't define a capability bit for the l2 translation.
Architecturally there is no way to tell guest that l2 translation
capability i
On 2016年10月21日 04:36, Andrew Cooper wrote:
>>
>>> u64 iova;
>>> /* Out parameters. */
>>> u64 translated_addr;
>>> u64 addr_mask; /* Translation page size */
>>> IOMMUAccessFlags permisson;
>>
>> How
On 10/26/2016 5:39 PM, Jan Beulich wrote:
On 22.10.16 at 09:32, wrote:
On 10/21/2016 4:36 AM, Andrew Cooper wrote:
3.5 Implementation consideration
VT-d spec doesn't define a capability bit for the l2 translation.
Architecturally there is no way to tell guest that l2 translation
capability i
On 10/26/2016 5:36 PM, Jan Beulich wrote:
On 18.10.16 at 16:14, wrote:
1.1 Enable more than 255 vcpu support
HPC cloud service requires VM provides high performance parallel
computing and we hope to create a huge VM with >255 vcpu on one machine
to meet such requirement.Ping each vcpus on separ
>>> On 22.10.16 at 09:32, wrote:
> On 10/21/2016 4:36 AM, Andrew Cooper wrote:
> 3.5 Implementation consideration
> VT-d spec doesn't define a capability bit for the l2 translation.
> Architecturally there is no way to tell guest that l2 translation
> capability is not available. L
>>> On 18.10.16 at 16:14, wrote:
> 1.1 Enable more than 255 vcpu support
> HPC cloud service requires VM provides high performance parallel
> computing and we hope to create a huge VM with >255 vcpu on one machine
> to meet such requirement.Ping each vcpus on separated pcpus. More than
> 255 vcpus
On 10/21/2016 4:36 AM, Andrew Cooper wrote:
255 vcpus support requires X2APIC and Linux disables X2APIC mode if
there is no interrupt remapping function which is present by vIOMMU.
Interrupt remapping function helps to deliver interrupt to #vcpu >255.
This is only a requirement for xapic
>
>>
>>> 255 vcpus support requires X2APIC and Linux disables X2APIC mode if
>>> there is no interrupt remapping function which is present by vIOMMU.
>>> Interrupt remapping function helps to deliver interrupt to #vcpu >255.
>>
>> This is only a requirement for xapic interrupt sources. x2apic
>>
On 20/10/16 10:53, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, October 19, 2016 3:18 AM
>>
>>> 1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
>>> It relies on the l2 translation capability (IOVA->GPA) on
>>> vIOMMU. pIOMMU l2 b
On 10/19/2016 4:26 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Oct 18, 2016 at 10:14:16PM +0800, Lan Tianyu wrote:
1 Motivation for Xen vIOMMU
===
1.1 Enable more than 255 vcpu support
HPC cloud service requires VM provi
Hi Andrew:
Thanks for your review.
On 2016年10月19日 03:17, Andrew Cooper wrote:
On 18/10/16 15:14, Lan Tianyu wrote:
Change since V1:
1) Update motivation for Xen vIOMMU - 288 vcpus support part
2) Change definition of struct xen_sysctl_viommu_op
3) Update "3.5 Implementation
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Wednesday, October 19, 2016 4:27 AM
> >
> > 2) For physical PCI device
> > DMA operations go though physical IOMMU directly and IO page table for
> > IOVA->HPA should be loaded into physical IOMMU. When guest updates
> > l2 Page-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, October 19, 2016 3:18 AM
>
> >
> > 1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
> > It relies on the l2 translation capability (IOVA->GPA) on
> > vIOMMU. pIOMMU l2 becomes a shadowing structure of
> >
On Tue, Oct 18, 2016 at 10:14:16PM +0800, Lan Tianyu wrote:
> Change since V1:
> 1) Update motivation for Xen vIOMMU - 288 vcpus support part
> 2) Change definition of struct xen_sysctl_viommu_op
> 3) Update "3.5 Implementation consideration" to explain why we needs to
> enable l2
On 18/10/16 15:14, Lan Tianyu wrote:
> Change since V1:
> 1) Update motivation for Xen vIOMMU - 288 vcpus support part
> 2) Change definition of struct xen_sysctl_viommu_op
> 3) Update "3.5 Implementation consideration" to explain why we
> needs to enable l2 translation first.
> 4)
Change since V1:
1) Update motivation for Xen vIOMMU - 288 vcpus support part
2) Change definition of struct xen_sysctl_viommu_op
3) Update "3.5 Implementation consideration" to explain why we needs to
enable l2 translation first.
4) Update "4.3 Q35 vs I440x" - Linux/Windows VTD
On 2016年10月06日 02:36, Konrad Rzeszutek Wilk wrote:
>>> 3.3 Interrupt remapping
>>> > > Interrupts from virtual devices and physical devices will be delivered
>>> > > to vlapic from vIOAPIC and vMSI. It needs to add interrupt remapping
>>> > > hooks in the vmsi_deliver() and ioapic_deliver() to find
On Thu, Sep 15, 2016 at 10:22:36PM +0800, Lan, Tianyu wrote:
> Hi Andrew:
> Sorry to bother you. To make sure we are on the right direction, it's
> better to get feedback from you before we go further step. Could you
> have a look? Thanks.
>
> On 8/17/2016 8:05 PM, Lan, Tianyu wrote:
> > Hi All:
>
Hi Andrew:
Sorry to bother you. To make sure we are on the right direction, it's
better to get feedback from you before we go further step. Could you
have a look? Thanks.
On 8/17/2016 8:05 PM, Lan, Tianyu wrote:
Hi All:
The following is our Xen vIOMMU high level design for detail
discussion
On 2016年08月31日 20:02, Jan Beulich wrote:
On 31.08.16 at 10:39, wrote:
>> > On 2016年08月25日 19:11, Jan Beulich wrote:
>> > On 17.08.16 at 14:05, wrote:
>>> 1 Motivation for Xen vIOMMU
>>>
>>> ==
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 31, 2016 8:03 PM
> >>> 3.5 Implementation consideration
> >>> Linux Intel IOMMU driver will fail to be loaded without 2th level
> >>> translation support even if interrupt remapping and 1th level
> >>> translation are availabl
>>> On 31.08.16 at 10:39, wrote:
> On 2016年08月25日 19:11, Jan Beulich wrote:
> On 17.08.16 at 14:05, wrote:
>>> 1 Motivation for Xen vIOMMU
>>>
>>> ===
>>> 1.1 Enable more than 255 vcpu support
>>> HPC virtualization
Hi Jan:
Sorry for later response. Thanks a lot for your comments.
On 2016年08月25日 19:11, Jan Beulich wrote:
On 17.08.16 at 14:05, wrote:
>> 1 Motivation for Xen vIOMMU
>>
>> ===
>> 1.1 Enable more than 255 vc
>>> On 17.08.16 at 14:05, wrote:
> 1 Motivation for Xen vIOMMU
>
> ===
> 1.1 Enable more than 255 vcpu support
> HPC virtualization requires more than 255 vcpus support in a single VM
> to meet parallel computing requirem
Perard; xuqu...@huawei.com; xen-
de...@lists.xensource.com; Ian Jackson; Roger Pau Monne
Subject: [Xen-devel] Xen virtual IOMMU high level design doc
Hi All:
The following is our Xen vIOMMU high level design for detail
discussion. Please have a look. Very appreciate for your comments.
This
qu...@huawei.com; xen-
> de...@lists.xensource.com; Ian Jackson; Roger Pau Monne
> Subject: [Xen-devel] Xen virtual IOMMU high level design doc
>
> Hi All:
> The following is our Xen vIOMMU high level design for detail
> discussion. Please have a look. Very appreciate for you
Hi All:
The following is our Xen vIOMMU high level design for detail
discussion. Please have a look. Very appreciate for your comments.
This design doesn't cover changes when root port is moved to hypervisor.
We may design it later.
Content:
=
47 matches
Mail list logo
