| Message ID | 1489750043-17260-6-git-send-email-tianyu.lan@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: > From: Chao Gao <chao.gao@intel.com> > > In previous patch, we introduce a common vIOMMU layer. In our design, > we create/destroy vIOMMU through DMOP interface instead of creating it > according to a config flag of domain. It makes it is possible > to create vIOMMU in device model or in tool stack. > > The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls: Hypercalls, not syscalls. > - query capabilities of vIOMMU emulated by Xen > - create vIOMMU in Xen hypervisor with base address, capability > - destroy vIOMMU specified by viommu_id > > Signed-off-by: Chao Gao <chao.gao@intel.com> > Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> > --- > tools/libs/devicemodel/core.c | 69 +++++++++++++++++++++++++ > tools/libs/devicemodel/include/xendevicemodel.h | 35 +++++++++++++ > tools/libs/devicemodel/libxendevicemodel.map | 3 ++ > tools/libxc/include/xenctrl_compat.h | 5 ++ > tools/libxc/xc_devicemodel_compat.c | 18 +++++++ > 5 files changed, 130 insertions(+) > > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c > index a85cb49..aee1150 100644 > --- a/tools/libs/devicemodel/core.c > +++ b/tools/libs/devicemodel/core.c Bear in mind that this library is stable, so whatever ends up here can change in the future. This is not saying the following code is problematic. It is just a general FYI. Obviously the toolstack side is going to follow the hypervisor interface, so I will do a detailed review later. > +int xendevicemodel_viommu_destroy( > + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id); > #endif /* __XEN_TOOLS__ */ > > #endif /* XENDEVICEMODEL_H */ > diff --git a/tools/libs/devicemodel/libxendevicemodel.map b/tools/libs/devicemodel/libxendevicemodel.map > index 45c773e..c2e0968 100644 > --- a/tools/libs/devicemodel/libxendevicemodel.map > +++ b/tools/libs/devicemodel/libxendevicemodel.map > @@ -17,6 +17,9 @@ VERS_1.0 { > xendevicemodel_modified_memory; > xendevicemodel_set_mem_type; > xendevicemodel_inject_event; > + xendevicemodel_viommu_query_cap; > + xendevicemodel_viommu_create; > + xendevicemodel_viommu_destroy; > xendevicemodel_restrict; > xendevicemodel_close; I suppose this series is going to miss 4.9. Please add these functions to VERS_1.1. > local: *; /* Do not expose anything by default */ > diff --git a/tools/libxc/include/xenctrl_compat.h b/tools/libxc/include/xenctrl_compat.h > index 040e7b2..315c45d 100644 > --- a/tools/libxc/include/xenctrl_compat.h > +++ b/tools/libxc/include/xenctrl_compat.h > @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( > int xc_hvm_inject_trap( > xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, > uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); > +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t *cap); > +int xc_viommu_create( > + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, > + uint32_t *viommu_id); > +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t viommu_id); > > #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ > > diff --git a/tools/libxc/xc_devicemodel_compat.c b/tools/libxc/xc_devicemodel_compat.c > index e4edeea..62f703a 100644 > --- a/tools/libxc/xc_devicemodel_compat.c > +++ b/tools/libxc/xc_devicemodel_compat.c I don't think you need to provide compat wrappers for them. They are new APIs. Wei.
Tianyu is on vacation this two weeks, so I will try to address some comments on this series. On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: >On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: >> From: Chao Gao <chao.gao@intel.com> >> >> In previous patch, we introduce a common vIOMMU layer. In our design, >> we create/destroy vIOMMU through DMOP interface instead of creating it >> according to a config flag of domain. It makes it is possible >> to create vIOMMU in device model or in tool stack. >> >> The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls: > >Hypercalls, not syscalls. > >> - query capabilities of vIOMMU emulated by Xen >> - create vIOMMU in Xen hypervisor with base address, capability >> - destroy vIOMMU specified by viommu_id >> >> Signed-off-by: Chao Gao <chao.gao@intel.com> >> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> >> --- >> tools/libs/devicemodel/core.c | 69 +++++++++++++++++++++++++ >> tools/libs/devicemodel/include/xendevicemodel.h | 35 +++++++++++++ >> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ >> tools/libxc/include/xenctrl_compat.h | 5 ++ >> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ >> 5 files changed, 130 insertions(+) >> >> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c >> index a85cb49..aee1150 100644 >> --- a/tools/libs/devicemodel/core.c >> +++ b/tools/libs/devicemodel/core.c > >Bear in mind that this library is stable, so whatever ends up here can >change in the future. > >This is not saying the following code is problematic. It is just a >general FYI. > >Obviously the toolstack side is going to follow the hypervisor >interface, so I will do a detailed review later. Sure. If the hypervisor interface settles down, we can inform you. > >> +int xendevicemodel_viommu_destroy( >> + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id); >> #endif /* __XEN_TOOLS__ */ >> >> #endif /* XENDEVICEMODEL_H */ >> diff --git a/tools/libs/devicemodel/libxendevicemodel.map b/tools/libs/devicemodel/libxendevicemodel.map >> index 45c773e..c2e0968 100644 >> --- a/tools/libs/devicemodel/libxendevicemodel.map >> +++ b/tools/libs/devicemodel/libxendevicemodel.map >> @@ -17,6 +17,9 @@ VERS_1.0 { >> xendevicemodel_modified_memory; >> xendevicemodel_set_mem_type; >> xendevicemodel_inject_event; >> + xendevicemodel_viommu_query_cap; >> + xendevicemodel_viommu_create; >> + xendevicemodel_viommu_destroy; >> xendevicemodel_restrict; >> xendevicemodel_close; > >I suppose this series is going to miss 4.9. > >Please add these functions to VERS_1.1. Yes. We will fix this. > >> local: *; /* Do not expose anything by default */ >> diff --git a/tools/libxc/include/xenctrl_compat.h b/tools/libxc/include/xenctrl_compat.h >> index 040e7b2..315c45d 100644 >> --- a/tools/libxc/include/xenctrl_compat.h >> +++ b/tools/libxc/include/xenctrl_compat.h >> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( >> int xc_hvm_inject_trap( >> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, >> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); >> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t *cap); >> +int xc_viommu_create( >> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, >> + uint32_t *viommu_id); >> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t viommu_id); >> >> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ >> >> diff --git a/tools/libxc/xc_devicemodel_compat.c b/tools/libxc/xc_devicemodel_compat.c >> index e4edeea..62f703a 100644 >> --- a/tools/libxc/xc_devicemodel_compat.c >> +++ b/tools/libxc/xc_devicemodel_compat.c > >I don't think you need to provide compat wrappers for them. They are new >APIs. OK. Got it. Thanks, Chao > >Wei.
> -----Original Message----- > From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of > Chao Gao > Sent: 29 March 2017 01:40 > To: Wei Liu <wei.liu2@citrix.com> > Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; > Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu > operations in libxc > > Tianyu is on vacation this two weeks, so I will try to address > some comments on this series. > > On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: > >On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: > >> From: Chao Gao <chao.gao@intel.com> > >> > >> In previous patch, we introduce a common vIOMMU layer. In our design, > >> we create/destroy vIOMMU through DMOP interface instead of creating > it > >> according to a config flag of domain. It makes it is possible > >> to create vIOMMU in device model or in tool stack. > >> I've not been following this closely so apologies if this has already been asked... Why would you need to create a vIOMMU instance in an external device model. Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? Paul > >> The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls: > > > >Hypercalls, not syscalls. > > > >> - query capabilities of vIOMMU emulated by Xen > >> - create vIOMMU in Xen hypervisor with base address, capability > >> - destroy vIOMMU specified by viommu_id > >> > >> Signed-off-by: Chao Gao <chao.gao@intel.com> > >> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> > >> --- > >> tools/libs/devicemodel/core.c | 69 > +++++++++++++++++++++++++ > >> tools/libs/devicemodel/include/xendevicemodel.h | 35 +++++++++++++ > >> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ > >> tools/libxc/include/xenctrl_compat.h | 5 ++ > >> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ > >> 5 files changed, 130 insertions(+) > >> > >> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c > >> index a85cb49..aee1150 100644 > >> --- a/tools/libs/devicemodel/core.c > >> +++ b/tools/libs/devicemodel/core.c > > > >Bear in mind that this library is stable, so whatever ends up here can > >change in the future. > > > >This is not saying the following code is problematic. It is just a > >general FYI. > > > >Obviously the toolstack side is going to follow the hypervisor > >interface, so I will do a detailed review later. > > Sure. If the hypervisor interface settles down, we can inform you. > > > > >> +int xendevicemodel_viommu_destroy( > >> + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id); > >> #endif /* __XEN_TOOLS__ */ > >> > >> #endif /* XENDEVICEMODEL_H */ > >> diff --git a/tools/libs/devicemodel/libxendevicemodel.map > b/tools/libs/devicemodel/libxendevicemodel.map > >> index 45c773e..c2e0968 100644 > >> --- a/tools/libs/devicemodel/libxendevicemodel.map > >> +++ b/tools/libs/devicemodel/libxendevicemodel.map > >> @@ -17,6 +17,9 @@ VERS_1.0 { > >> xendevicemodel_modified_memory; > >> xendevicemodel_set_mem_type; > >> xendevicemodel_inject_event; > >> + xendevicemodel_viommu_query_cap; > >> + xendevicemodel_viommu_create; > >> + xendevicemodel_viommu_destroy; > >> xendevicemodel_restrict; > >> xendevicemodel_close; > > > >I suppose this series is going to miss 4.9. > > > >Please add these functions to VERS_1.1. > > Yes. We will fix this. > > > > >> local: *; /* Do not expose anything by default */ > >> diff --git a/tools/libxc/include/xenctrl_compat.h > b/tools/libxc/include/xenctrl_compat.h > >> index 040e7b2..315c45d 100644 > >> --- a/tools/libxc/include/xenctrl_compat.h > >> +++ b/tools/libxc/include/xenctrl_compat.h > >> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( > >> int xc_hvm_inject_trap( > >> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, > >> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); > >> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t > *cap); > >> +int xc_viommu_create( > >> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, > >> + uint32_t *viommu_id); > >> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t > viommu_id); > >> > >> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ > >> > >> diff --git a/tools/libxc/xc_devicemodel_compat.c > b/tools/libxc/xc_devicemodel_compat.c > >> index e4edeea..62f703a 100644 > >> --- a/tools/libxc/xc_devicemodel_compat.c > >> +++ b/tools/libxc/xc_devicemodel_compat.c > > > >I don't think you need to provide compat wrappers for them. They are new > >APIs. > > OK. Got it. > > Thanks, > Chao > > > >Wei. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of >> Chao Gao >> Sent: 29 March 2017 01:40 >> To: Wei Liu <wei.liu2@citrix.com> >> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; >> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu >> operations in libxc >> >> Tianyu is on vacation this two weeks, so I will try to address >> some comments on this series. >> >> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: >> >On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: >> >> From: Chao Gao <chao.gao@intel.com> >> >> >> >> In previous patch, we introduce a common vIOMMU layer. In our design, >> >> we create/destroy vIOMMU through DMOP interface instead of creating >> it >> >> according to a config flag of domain. It makes it is possible >> >> to create vIOMMU in device model or in tool stack. >> >> > >I've not been following this closely so apologies if this has already been asked... > >Why would you need to create a vIOMMU instance in an external device model. > Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? I assume your question is why we don't create a vIOMMU instance via hypercall in toolstack. I think creating in toolstack is also ok and is easier to be reused by pvh. If Tianyu has no concern about this, will move this part to toolstack. Thanks, Chao > > Paul > >> >> The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls: >> > >> >Hypercalls, not syscalls. >> > >> >> - query capabilities of vIOMMU emulated by Xen >> >> - create vIOMMU in Xen hypervisor with base address, capability >> >> - destroy vIOMMU specified by viommu_id >> >> >> >> Signed-off-by: Chao Gao <chao.gao@intel.com> >> >> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> >> >> --- >> >> tools/libs/devicemodel/core.c | 69 >> +++++++++++++++++++++++++ >> >> tools/libs/devicemodel/include/xendevicemodel.h | 35 +++++++++++++ >> >> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ >> >> tools/libxc/include/xenctrl_compat.h | 5 ++ >> >> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ >> >> 5 files changed, 130 insertions(+) >> >> >> >> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c >> >> index a85cb49..aee1150 100644 >> >> --- a/tools/libs/devicemodel/core.c >> >> +++ b/tools/libs/devicemodel/core.c >> > >> >Bear in mind that this library is stable, so whatever ends up here can >> >change in the future. >> > >> >This is not saying the following code is problematic. It is just a >> >general FYI. >> > >> >Obviously the toolstack side is going to follow the hypervisor >> >interface, so I will do a detailed review later. >> >> Sure. If the hypervisor interface settles down, we can inform you. >> >> > >> >> +int xendevicemodel_viommu_destroy( >> >> + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id); >> >> #endif /* __XEN_TOOLS__ */ >> >> >> >> #endif /* XENDEVICEMODEL_H */ >> >> diff --git a/tools/libs/devicemodel/libxendevicemodel.map >> b/tools/libs/devicemodel/libxendevicemodel.map >> >> index 45c773e..c2e0968 100644 >> >> --- a/tools/libs/devicemodel/libxendevicemodel.map >> >> +++ b/tools/libs/devicemodel/libxendevicemodel.map >> >> @@ -17,6 +17,9 @@ VERS_1.0 { >> >> xendevicemodel_modified_memory; >> >> xendevicemodel_set_mem_type; >> >> xendevicemodel_inject_event; >> >> + xendevicemodel_viommu_query_cap; >> >> + xendevicemodel_viommu_create; >> >> + xendevicemodel_viommu_destroy; >> >> xendevicemodel_restrict; >> >> xendevicemodel_close; >> > >> >I suppose this series is going to miss 4.9. >> > >> >Please add these functions to VERS_1.1. >> >> Yes. We will fix this. >> >> > >> >> local: *; /* Do not expose anything by default */ >> >> diff --git a/tools/libxc/include/xenctrl_compat.h >> b/tools/libxc/include/xenctrl_compat.h >> >> index 040e7b2..315c45d 100644 >> >> --- a/tools/libxc/include/xenctrl_compat.h >> >> +++ b/tools/libxc/include/xenctrl_compat.h >> >> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( >> >> int xc_hvm_inject_trap( >> >> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, >> >> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); >> >> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t >> *cap); >> >> +int xc_viommu_create( >> >> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, >> >> + uint32_t *viommu_id); >> >> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t >> viommu_id); >> >> >> >> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ >> >> >> >> diff --git a/tools/libxc/xc_devicemodel_compat.c >> b/tools/libxc/xc_devicemodel_compat.c >> >> index e4edeea..62f703a 100644 >> >> --- a/tools/libxc/xc_devicemodel_compat.c >> >> +++ b/tools/libxc/xc_devicemodel_compat.c >> > >> >I don't think you need to provide compat wrappers for them. They are new >> >APIs. >> >> OK. Got it. >> >> Thanks, >> Chao >> > >> >Wei. >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> https://lists.xen.org/xen-devel
Hi Paul: Sorry for later response. On 3/31/2017 3:57 AM, Chao Gao wrote: > On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: >>> -----Original Message----- >>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of >>> Chao Gao >>> Sent: 29 March 2017 01:40 >>> To: Wei Liu <wei.liu2@citrix.com> >>> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; >>> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org >>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu >>> operations in libxc >>> >>> Tianyu is on vacation this two weeks, so I will try to address >>> some comments on this series. >>> >>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: >>>> On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: >>>>> From: Chao Gao <chao.gao@intel.com> >>>>> >>>>> In previous patch, we introduce a common vIOMMU layer. In our design, >>>>> we create/destroy vIOMMU through DMOP interface instead of creating >>> it >>>>> according to a config flag of domain. It makes it is possible >>>>> to create vIOMMU in device model or in tool stack. >>>>> >> >> I've not been following this closely so apologies if this has already been asked... >> >> Why would you need to create a vIOMMU instance in an external device model. >> Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? > > I assume your question is why we don't create a vIOMMU instance via hypercall in toolstack. > I think creating in toolstack is also ok and is easier to be reused by pvh. > > If Tianyu has no concern about this, will move this part to toolstack. We can move create/destroy vIOMMU in the tool stack but we still need to add such dummy vIOMMU device model in Qemu to pass virtual device's DMA request into Xen hypervisor. Qemu is required to use DMOP hypercall and tool stack may use domctl hyercall. vIOMMU hypercalls will be divided into two part. Domctl: create, destroy and query. DMOP: vDev's DMA related operations. Is this OK? > > Thanks, > Chao > >> >> Paul >> >>>>> The following toolstack code is to add XEN_DMOP_viommu_XXX syscalls: >>>> >>>> Hypercalls, not syscalls. >>>> >>>>> - query capabilities of vIOMMU emulated by Xen >>>>> - create vIOMMU in Xen hypervisor with base address, capability >>>>> - destroy vIOMMU specified by viommu_id >>>>> >>>>> Signed-off-by: Chao Gao <chao.gao@intel.com> >>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> >>>>> --- >>>>> tools/libs/devicemodel/core.c | 69 >>> +++++++++++++++++++++++++ >>>>> tools/libs/devicemodel/include/xendevicemodel.h | 35 +++++++++++++ >>>>> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ >>>>> tools/libxc/include/xenctrl_compat.h | 5 ++ >>>>> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ >>>>> 5 files changed, 130 insertions(+) >>>>> >>>>> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c >>>>> index a85cb49..aee1150 100644 >>>>> --- a/tools/libs/devicemodel/core.c >>>>> +++ b/tools/libs/devicemodel/core.c >>>> >>>> Bear in mind that this library is stable, so whatever ends up here can >>>> change in the future. >>>> >>>> This is not saying the following code is problematic. It is just a >>>> general FYI. >>>> >>>> Obviously the toolstack side is going to follow the hypervisor >>>> interface, so I will do a detailed review later. >>> >>> Sure. If the hypervisor interface settles down, we can inform you. >>> >>>> >>>>> +int xendevicemodel_viommu_destroy( >>>>> + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id); >>>>> #endif /* __XEN_TOOLS__ */ >>>>> >>>>> #endif /* XENDEVICEMODEL_H */ >>>>> diff --git a/tools/libs/devicemodel/libxendevicemodel.map >>> b/tools/libs/devicemodel/libxendevicemodel.map >>>>> index 45c773e..c2e0968 100644 >>>>> --- a/tools/libs/devicemodel/libxendevicemodel.map >>>>> +++ b/tools/libs/devicemodel/libxendevicemodel.map >>>>> @@ -17,6 +17,9 @@ VERS_1.0 { >>>>> xendevicemodel_modified_memory; >>>>> xendevicemodel_set_mem_type; >>>>> xendevicemodel_inject_event; >>>>> + xendevicemodel_viommu_query_cap; >>>>> + xendevicemodel_viommu_create; >>>>> + xendevicemodel_viommu_destroy; >>>>> xendevicemodel_restrict; >>>>> xendevicemodel_close; >>>> >>>> I suppose this series is going to miss 4.9. >>>> >>>> Please add these functions to VERS_1.1. >>> >>> Yes. We will fix this. >>> >>>> >>>>> local: *; /* Do not expose anything by default */ >>>>> diff --git a/tools/libxc/include/xenctrl_compat.h >>> b/tools/libxc/include/xenctrl_compat.h >>>>> index 040e7b2..315c45d 100644 >>>>> --- a/tools/libxc/include/xenctrl_compat.h >>>>> +++ b/tools/libxc/include/xenctrl_compat.h >>>>> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( >>>>> int xc_hvm_inject_trap( >>>>> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, >>>>> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); >>>>> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t >>> *cap); >>>>> +int xc_viommu_create( >>>>> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, >>>>> + uint32_t *viommu_id); >>>>> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t >>> viommu_id); >>>>> >>>>> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ >>>>> >>>>> diff --git a/tools/libxc/xc_devicemodel_compat.c >>> b/tools/libxc/xc_devicemodel_compat.c >>>>> index e4edeea..62f703a 100644 >>>>> --- a/tools/libxc/xc_devicemodel_compat.c >>>>> +++ b/tools/libxc/xc_devicemodel_compat.c >>>> >>>> I don't think you need to provide compat wrappers for them. They are new >>>> APIs. >>> >>> OK. Got it. >>> >>> Thanks, >>> Chao >>>> >>>> Wei. >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> https://lists.xen.org/xen-devel
On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote: > Hi Paul: > Sorry for later response. > > On 3/31/2017 3:57 AM, Chao Gao wrote: > > On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: > > > > -----Original Message----- > > > > From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of > > > > Chao Gao > > > > Sent: 29 March 2017 01:40 > > > > To: Wei Liu <wei.liu2@citrix.com> > > > > Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; > > > > Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org > > > > Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu > > > > operations in libxc > > > > > > > > Tianyu is on vacation this two weeks, so I will try to address > > > > some comments on this series. > > > > > > > > On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: > > > > > On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: > > > > > > From: Chao Gao <chao.gao@intel.com> > > > > > > > > > > > > In previous patch, we introduce a common vIOMMU layer. In our design, > > > > > > we create/destroy vIOMMU through DMOP interface instead of creating > > > > it > > > > > > according to a config flag of domain. It makes it is possible > > > > > > to create vIOMMU in device model or in tool stack. > > > > > > > > > > > > I've not been following this closely so apologies if this has already been asked... > > > > > > Why would you need to create a vIOMMU instance in an external device model. > > > Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? > > > > I assume your question is why we don't create a vIOMMU instance via hypercall in toolstack. > > I think creating in toolstack is also ok and is easier to be reused by pvh. > > > > If Tianyu has no concern about this, will move this part to toolstack. > > We can move create/destroy vIOMMU in the tool stack but we still need to add > such dummy vIOMMU device model in Qemu to pass virtual device's DMA request > into Xen hypervisor. Qemu is required to use DMOP hypercall and tool stack > may use domctl hyercall. vIOMMU hypercalls will be divided into two part. > > Domctl: > create, destroy and query. > DMOP: > vDev's DMA related operations. > > Is this OK? > Why are they divided into two libraries? Can't they be in DMOP at the same time? Just asking questions, not suggesting it should be done one way or the other. Sorry if there are some obvious reasons that I missed. Wei.
On 2017年04月17日 19:08, Wei Liu wrote: > On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote: >> Hi Paul: >> Sorry for later response. >> >> On 3/31/2017 3:57 AM, Chao Gao wrote: >>> On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: >>>>> -----Original Message----- >>>>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of >>>>> Chao Gao >>>>> Sent: 29 March 2017 01:40 >>>>> To: Wei Liu <wei.liu2@citrix.com> >>>>> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; >>>>> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org >>>>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu >>>>> operations in libxc >>>>> >>>>> Tianyu is on vacation this two weeks, so I will try to address >>>>> some comments on this series. >>>>> >>>>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: >>>>>> On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: >>>>>>> From: Chao Gao <chao.gao@intel.com> >>>>>>> >>>>>>> In previous patch, we introduce a common vIOMMU layer. In our design, >>>>>>> we create/destroy vIOMMU through DMOP interface instead of creating >>>>> it >>>>>>> according to a config flag of domain. It makes it is possible >>>>>>> to create vIOMMU in device model or in tool stack. >>>>>>> >>>> >>>> I've not been following this closely so apologies if this has already been asked... >>>> >>>> Why would you need to create a vIOMMU instance in an external device model. >>>> Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? >>> >>> I assume your question is why we don't create a vIOMMU instance via hypercall in toolstack. >>> I think creating in toolstack is also ok and is easier to be reused by pvh. >>> >>> If Tianyu has no concern about this, will move this part to toolstack. >> >> We can move create/destroy vIOMMU in the tool stack but we still need to add >> such dummy vIOMMU device model in Qemu to pass virtual device's DMA request >> into Xen hypervisor. Qemu is required to use DMOP hypercall and tool stack >> may use domctl hyercall. vIOMMU hypercalls will be divided into two part. >> >> Domctl: >> create, destroy and query. >> DMOP: >> vDev's DMA related operations. >> >> Is this OK? >> > > Why are they divided into two libraries? Can't they be in DMOP at the > same time? Yes, we can use DMOP for all vIOMMU hyercalls if it's necessary to keep unified vIOMMU hyercall type. In theory, DMOP dedicates to be used by Qemu but we also can use it in tool stack. If we move create, destroy and query operation to tool stack, it isn't necessary to use DMOP for them since only tool stack will call them. This is why I said we could use domctl for these operations. Both two ways will not affect function implementation. Which one it's better from your view? :) > > Just asking questions, not suggesting it should be done one way or the > other. Sorry if there are some obvious reasons that I missed. > > Wei. >
> -----Original Message----- > From: Lan, Tianyu [mailto:tianyu.lan@intel.com] > Sent: 14 April 2017 16:38 > To: Paul Durrant <Paul.Durrant@citrix.com>; Wei Liu <wei.liu2@citrix.com>; > Kevin Tian <kevin.tian@intel.com>; Ian Jackson <Ian.Jackson@citrix.com>; > xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu > operations in libxc > > Hi Paul: > Sorry for later response. > > On 3/31/2017 3:57 AM, Chao Gao wrote: > > On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: > >>> -----Original Message----- > >>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf > Of > >>> Chao Gao > >>> Sent: 29 March 2017 01:40 > >>> To: Wei Liu <wei.liu2@citrix.com> > >>> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian > <kevin.tian@intel.com>; > >>> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org > >>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu > >>> operations in libxc > >>> > >>> Tianyu is on vacation this two weeks, so I will try to address > >>> some comments on this series. > >>> > >>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: > >>>> On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: > >>>>> From: Chao Gao <chao.gao@intel.com> > >>>>> > >>>>> In previous patch, we introduce a common vIOMMU layer. In our > design, > >>>>> we create/destroy vIOMMU through DMOP interface instead of > creating > >>> it > >>>>> according to a config flag of domain. It makes it is possible > >>>>> to create vIOMMU in device model or in tool stack. > >>>>> > >> > >> I've not been following this closely so apologies if this has already been > asked... > >> > >> Why would you need to create a vIOMMU instance in an external device > model. > >> Since the toolstack should be in control of the device model configuration > why would it not know in advance that one was required? > > > > I assume your question is why we don't create a vIOMMU instance via > hypercall in toolstack. > > I think creating in toolstack is also ok and is easier to be reused by pvh. > > > > If Tianyu has no concern about this, will move this part to toolstack. > > We can move create/destroy vIOMMU in the tool stack but we still need to > add such dummy vIOMMU device model in Qemu to pass virtual device's > DMA > request into Xen hypervisor. Not quite sure I understand this. The QEMu device model does not 'pass DMA requests' as such, it maps guest RAM and reads or writes to emulate DMA, right? So, what's needed is a mechanism to map guest RAM by 'bus address'... i.e. an address that will need to be translated through the vIOMMU mappings. This is just an evolution of the current 'priv mapping' operations that allow guest RAM to be mapped by guest physical address. So you don't need a vIOMMU 'device model' as such, do you? > Qemu is required to use DMOP hypercall and > tool stack may use domctl hyercall. vIOMMU hypercalls will be divided > into two part. > > Domctl: > create, destroy and query. > DMOP: > vDev's DMA related operations. Yes, the mapping/unmapping operations should be DMOPs and IMO should be designed such that they can be unified with replacements for current 'priv map' ops such that QEMU can use the same function call, but with different address space identifiers (i.e. bus address, guest physical address, etc.). BTW, I say 'etc.' because we should also consider mapping the ioreq pages from Xen using the same call - with a dedicated address space identifier - as well. Cheers, Paul > > Is this OK? > > > > > Thanks, > > Chao > > > >> > >> Paul > >> > >>>>> The following toolstack code is to add XEN_DMOP_viommu_XXX > syscalls: > >>>> > >>>> Hypercalls, not syscalls. > >>>> > >>>>> - query capabilities of vIOMMU emulated by Xen > >>>>> - create vIOMMU in Xen hypervisor with base address, capability > >>>>> - destroy vIOMMU specified by viommu_id > >>>>> > >>>>> Signed-off-by: Chao Gao <chao.gao@intel.com> > >>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> > >>>>> --- > >>>>> tools/libs/devicemodel/core.c | 69 > >>> +++++++++++++++++++++++++ > >>>>> tools/libs/devicemodel/include/xendevicemodel.h | 35 > +++++++++++++ > >>>>> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ > >>>>> tools/libxc/include/xenctrl_compat.h | 5 ++ > >>>>> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ > >>>>> 5 files changed, 130 insertions(+) > >>>>> > >>>>> diff --git a/tools/libs/devicemodel/core.c > b/tools/libs/devicemodel/core.c > >>>>> index a85cb49..aee1150 100644 > >>>>> --- a/tools/libs/devicemodel/core.c > >>>>> +++ b/tools/libs/devicemodel/core.c > >>>> > >>>> Bear in mind that this library is stable, so whatever ends up here can > >>>> change in the future. > >>>> > >>>> This is not saying the following code is problematic. It is just a > >>>> general FYI. > >>>> > >>>> Obviously the toolstack side is going to follow the hypervisor > >>>> interface, so I will do a detailed review later. > >>> > >>> Sure. If the hypervisor interface settles down, we can inform you. > >>> > >>>> > >>>>> +int xendevicemodel_viommu_destroy( > >>>>> + xendevicemodel_handle *dmod, domid_t dom, uint32_t > viommu_id); > >>>>> #endif /* __XEN_TOOLS__ */ > >>>>> > >>>>> #endif /* XENDEVICEMODEL_H */ > >>>>> diff --git a/tools/libs/devicemodel/libxendevicemodel.map > >>> b/tools/libs/devicemodel/libxendevicemodel.map > >>>>> index 45c773e..c2e0968 100644 > >>>>> --- a/tools/libs/devicemodel/libxendevicemodel.map > >>>>> +++ b/tools/libs/devicemodel/libxendevicemodel.map > >>>>> @@ -17,6 +17,9 @@ VERS_1.0 { > >>>>> xendevicemodel_modified_memory; > >>>>> xendevicemodel_set_mem_type; > >>>>> xendevicemodel_inject_event; > >>>>> + xendevicemodel_viommu_query_cap; > >>>>> + xendevicemodel_viommu_create; > >>>>> + xendevicemodel_viommu_destroy; > >>>>> xendevicemodel_restrict; > >>>>> xendevicemodel_close; > >>>> > >>>> I suppose this series is going to miss 4.9. > >>>> > >>>> Please add these functions to VERS_1.1. > >>> > >>> Yes. We will fix this. > >>> > >>>> > >>>>> local: *; /* Do not expose anything by default */ > >>>>> diff --git a/tools/libxc/include/xenctrl_compat.h > >>> b/tools/libxc/include/xenctrl_compat.h > >>>>> index 040e7b2..315c45d 100644 > >>>>> --- a/tools/libxc/include/xenctrl_compat.h > >>>>> +++ b/tools/libxc/include/xenctrl_compat.h > >>>>> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( > >>>>> int xc_hvm_inject_trap( > >>>>> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, > >>>>> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); > >>>>> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, > uint64_t > >>> *cap); > >>>>> +int xc_viommu_create( > >>>>> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t > cap, > >>>>> + uint32_t *viommu_id); > >>>>> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t > >>> viommu_id); > >>>>> > >>>>> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ > >>>>> > >>>>> diff --git a/tools/libxc/xc_devicemodel_compat.c > >>> b/tools/libxc/xc_devicemodel_compat.c > >>>>> index e4edeea..62f703a 100644 > >>>>> --- a/tools/libxc/xc_devicemodel_compat.c > >>>>> +++ b/tools/libxc/xc_devicemodel_compat.c > >>>> > >>>> I don't think you need to provide compat wrappers for them. They are > new > >>>> APIs. > >>> > >>> OK. Got it. > >>> > >>> Thanks, > >>> Chao > >>>> > >>>> Wei. > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xen.org > >>> https://lists.xen.org/xen-devel
On 2017年04月18日 17:08, Paul Durrant wrote: >> -----Original Message----- >> From: Lan, Tianyu [mailto:tianyu.lan@intel.com] >> Sent: 14 April 2017 16:38 >> To: Paul Durrant <Paul.Durrant@citrix.com>; Wei Liu <wei.liu2@citrix.com>; >> Kevin Tian <kevin.tian@intel.com>; Ian Jackson <Ian.Jackson@citrix.com>; >> xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu >> operations in libxc >> >> Hi Paul: >> Sorry for later response. >> >> On 3/31/2017 3:57 AM, Chao Gao wrote: >>> On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: >>>>> -----Original Message----- >>>>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf >> Of >>>>> Chao Gao >>>>> Sent: 29 March 2017 01:40 >>>>> To: Wei Liu <wei.liu2@citrix.com> >>>>> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian >> <kevin.tian@intel.com>; >>>>> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org >>>>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu >>>>> operations in libxc >>>>> >>>>> Tianyu is on vacation this two weeks, so I will try to address >>>>> some comments on this series. >>>>> >>>>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: >>>>>> On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: >>>>>>> From: Chao Gao <chao.gao@intel.com> >>>>>>> >>>>>>> In previous patch, we introduce a common vIOMMU layer. In our >> design, >>>>>>> we create/destroy vIOMMU through DMOP interface instead of >> creating >>>>> it >>>>>>> according to a config flag of domain. It makes it is possible >>>>>>> to create vIOMMU in device model or in tool stack. >>>>>>> >>>> >>>> I've not been following this closely so apologies if this has already been >> asked... >>>> >>>> Why would you need to create a vIOMMU instance in an external device >> model. >>>> Since the toolstack should be in control of the device model configuration >> why would it not know in advance that one was required? >>> >>> I assume your question is why we don't create a vIOMMU instance via >> hypercall in toolstack. >>> I think creating in toolstack is also ok and is easier to be reused by pvh. >>> >>> If Tianyu has no concern about this, will move this part to toolstack. >> >> We can move create/destroy vIOMMU in the tool stack but we still need to >> add such dummy vIOMMU device model in Qemu to pass virtual device's >> DMA >> request into Xen hypervisor. > > Not quite sure I understand this. The QEMu device model does not 'pass DMA requests' as such, it maps guest RAM and reads or writes to emulate DMA, right? So, what's needed is a mechanism to map guest RAM by 'bus address'... i.e. an address that will need to be translated through the vIOMMU mappings. This is just an evolution of the current 'priv mapping' operations that allow guest RAM to be mapped by guest physical address. So you don't need a vIOMMU 'device model' as such, do you? Guest also may enable DMA protection mechanism in linux kernel which limits address space of emulated device and this depends on the vIOMMU's DMA translation function. In vIOMMU's MMIO emulation part is in the Xen hypersior and the guest shadow IO page table will be only in the hypervisor. To translate emulated device's DMA request. It's necessary to pass the DMA request to hypervisor. So far we don't support DMA translation and so doesn't pass DMA request. Map/umap guest memory already support in Qemu and just like emulated device model access guest memory. Qemu also provides vIOMMU hook to receive DMA request and return target guest address. vIOMMU framework will read/write target address. What we need to do is to translate DMA request to target address according shadow IO page table in the hypervisor. > >> Qemu is required to use DMOP hypercall and >> tool stack may use domctl hyercall. vIOMMU hypercalls will be divided >> into two part. >> >> Domctl: >> create, destroy and query. >> DMOP: >> vDev's DMA related operations. > > Yes, the mapping/unmapping operations should be DMOPs and IMO should be designed such that they can be unified with replacements for current 'priv map' ops such that QEMU can use the same function call, but with different address space identifiers (i.e. bus address, guest physical address, etc.). BTW, I say 'etc.' because we should also consider mapping the ioreq pages from Xen using the same call - with a dedicated address space identifier - as well. > So you agree to divide vIOMMU's hypercalls into two parts(DMOP and Domctl), right? > Cheers, > > Paul > >> >> Is this OK? >> >>> >>> Thanks, >>> Chao >>> >>>> >>>> Paul >>>> >>>>>>> The following toolstack code is to add XEN_DMOP_viommu_XXX >> syscalls: >>>>>> >>>>>> Hypercalls, not syscalls. >>>>>> >>>>>>> - query capabilities of vIOMMU emulated by Xen >>>>>>> - create vIOMMU in Xen hypervisor with base address, capability >>>>>>> - destroy vIOMMU specified by viommu_id >>>>>>> >>>>>>> Signed-off-by: Chao Gao <chao.gao@intel.com> >>>>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> >>>>>>> --- >>>>>>> tools/libs/devicemodel/core.c | 69 >>>>> +++++++++++++++++++++++++ >>>>>>> tools/libs/devicemodel/include/xendevicemodel.h | 35 >> +++++++++++++ >>>>>>> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ >>>>>>> tools/libxc/include/xenctrl_compat.h | 5 ++ >>>>>>> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ >>>>>>> 5 files changed, 130 insertions(+) >>>>>>> >>>>>>> diff --git a/tools/libs/devicemodel/core.c >> b/tools/libs/devicemodel/core.c >>>>>>> index a85cb49..aee1150 100644 >>>>>>> --- a/tools/libs/devicemodel/core.c >>>>>>> +++ b/tools/libs/devicemodel/core.c >>>>>> >>>>>> Bear in mind that this library is stable, so whatever ends up here can >>>>>> change in the future. >>>>>> >>>>>> This is not saying the following code is problematic. It is just a >>>>>> general FYI. >>>>>> >>>>>> Obviously the toolstack side is going to follow the hypervisor >>>>>> interface, so I will do a detailed review later. >>>>> >>>>> Sure. If the hypervisor interface settles down, we can inform you. >>>>> >>>>>> >>>>>>> +int xendevicemodel_viommu_destroy( >>>>>>> + xendevicemodel_handle *dmod, domid_t dom, uint32_t >> viommu_id); >>>>>>> #endif /* __XEN_TOOLS__ */ >>>>>>> >>>>>>> #endif /* XENDEVICEMODEL_H */ >>>>>>> diff --git a/tools/libs/devicemodel/libxendevicemodel.map >>>>> b/tools/libs/devicemodel/libxendevicemodel.map >>>>>>> index 45c773e..c2e0968 100644 >>>>>>> --- a/tools/libs/devicemodel/libxendevicemodel.map >>>>>>> +++ b/tools/libs/devicemodel/libxendevicemodel.map >>>>>>> @@ -17,6 +17,9 @@ VERS_1.0 { >>>>>>> xendevicemodel_modified_memory; >>>>>>> xendevicemodel_set_mem_type; >>>>>>> xendevicemodel_inject_event; >>>>>>> + xendevicemodel_viommu_query_cap; >>>>>>> + xendevicemodel_viommu_create; >>>>>>> + xendevicemodel_viommu_destroy; >>>>>>> xendevicemodel_restrict; >>>>>>> xendevicemodel_close; >>>>>> >>>>>> I suppose this series is going to miss 4.9. >>>>>> >>>>>> Please add these functions to VERS_1.1. >>>>> >>>>> Yes. We will fix this. >>>>> >>>>>> >>>>>>> local: *; /* Do not expose anything by default */ >>>>>>> diff --git a/tools/libxc/include/xenctrl_compat.h >>>>> b/tools/libxc/include/xenctrl_compat.h >>>>>>> index 040e7b2..315c45d 100644 >>>>>>> --- a/tools/libxc/include/xenctrl_compat.h >>>>>>> +++ b/tools/libxc/include/xenctrl_compat.h >>>>>>> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( >>>>>>> int xc_hvm_inject_trap( >>>>>>> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, >>>>>>> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); >>>>>>> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, >> uint64_t >>>>> *cap); >>>>>>> +int xc_viommu_create( >>>>>>> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t >> cap, >>>>>>> + uint32_t *viommu_id); >>>>>>> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t >>>>> viommu_id); >>>>>>> >>>>>>> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ >>>>>>> >>>>>>> diff --git a/tools/libxc/xc_devicemodel_compat.c >>>>> b/tools/libxc/xc_devicemodel_compat.c >>>>>>> index e4edeea..62f703a 100644 >>>>>>> --- a/tools/libxc/xc_devicemodel_compat.c >>>>>>> +++ b/tools/libxc/xc_devicemodel_compat.c >>>>>> >>>>>> I don't think you need to provide compat wrappers for them. They are >> new >>>>>> APIs. >>>>> >>>>> OK. Got it. >>>>> >>>>> Thanks, >>>>> Chao >>>>>> >>>>>> Wei. >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xen.org >>>>> https://lists.xen.org/xen-devel
> -----Original Message----- [snip] > > > > Not quite sure I understand this. The QEMu device model does not 'pass > DMA requests' as such, it maps guest RAM and reads or writes to emulate > DMA, right? So, what's needed is a mechanism to map guest RAM by 'bus > address'... i.e. an address that will need to be translated through the > vIOMMU mappings. This is just an evolution of the current 'priv mapping' > operations that allow guest RAM to be mapped by guest physical address. So > you don't need a vIOMMU 'device model' as such, do you? > > > Guest also may enable DMA protection mechanism in linux kernel which > limits address space of emulated device and this depends on the vIOMMU's > DMA translation function. In vIOMMU's MMIO emulation part is in the Xen > hypersior and the guest shadow IO page table will be only in the > hypervisor. To translate emulated device's DMA request. It's necessary > to pass the DMA request to hypervisor. > What do you mean by DMA request though? Are you intending to make some form of hypercall to read or write guest memory? If so then why not introduce a call to map the guest memory (via bus address) and read or write directly. > So far we don't support DMA translation and so doesn't pass DMA request. > Indeed. We map guest memory using guest physical address because, without an emulated IOMMU, guest physical address === bus address. This is why I suggest a new mapping operation rather than 'passing a DMA request' to the hypervisor. > Map/umap guest memory already support in Qemu and just like emulated > device model access guest memory. Qemu also provides vIOMMU hook to > receive DMA request and return target guest address. vIOMMU framework > will read/write target address. That's the part I don't get... why have the vIOMMU code do the reads and writes? Why not have it provide a mapping function and then have the device model in QEMU read and write directly as it does now? > What we need to do is to translate DMA > request to target address according shadow IO page table in the hypervisor. > Yes, so the mapping has to be done by the hypervisor (as is the case for priv mapping or grant mapping) but the memory accesses themselves can be done directly by the device model in QEMU. > > > > > >> Qemu is required to use DMOP hypercall and > >> tool stack may use domctl hyercall. vIOMMU hypercalls will be divided > >> into two part. > >> > >> Domctl: > >> create, destroy and query. > >> DMOP: > >> vDev's DMA related operations. > > > > Yes, the mapping/unmapping operations should be DMOPs and IMO > should be designed such that they can be unified with replacements for > current 'priv map' ops such that QEMU can use the same function call, but > with different address space identifiers (i.e. bus address, guest physical > address, etc.). BTW, I say 'etc.' because we should also consider mapping the > ioreq pages from Xen using the same call - with a dedicated address space > identifier - as well. > > > > So you agree to divide vIOMMU's hypercalls into two parts(DMOP and > Domctl), right? > Yes, I agree with the logic of the split. Cheers, Paul > > > Cheers, > > > > Paul > > > >> > >> Is this OK? > >> > >>> > >>> Thanks, > >>> Chao > >>> > >>>> > >>>> Paul > >>>> > >>>>>>> The following toolstack code is to add XEN_DMOP_viommu_XXX > >> syscalls: > >>>>>> > >>>>>> Hypercalls, not syscalls. > >>>>>> > >>>>>>> - query capabilities of vIOMMU emulated by Xen > >>>>>>> - create vIOMMU in Xen hypervisor with base address, capability > >>>>>>> - destroy vIOMMU specified by viommu_id > >>>>>>> > >>>>>>> Signed-off-by: Chao Gao <chao.gao@intel.com> > >>>>>>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> > >>>>>>> --- > >>>>>>> tools/libs/devicemodel/core.c | 69 > >>>>> +++++++++++++++++++++++++ > >>>>>>> tools/libs/devicemodel/include/xendevicemodel.h | 35 > >> +++++++++++++ > >>>>>>> tools/libs/devicemodel/libxendevicemodel.map | 3 ++ > >>>>>>> tools/libxc/include/xenctrl_compat.h | 5 ++ > >>>>>>> tools/libxc/xc_devicemodel_compat.c | 18 +++++++ > >>>>>>> 5 files changed, 130 insertions(+) > >>>>>>> > >>>>>>> diff --git a/tools/libs/devicemodel/core.c > >> b/tools/libs/devicemodel/core.c > >>>>>>> index a85cb49..aee1150 100644 > >>>>>>> --- a/tools/libs/devicemodel/core.c > >>>>>>> +++ b/tools/libs/devicemodel/core.c > >>>>>> > >>>>>> Bear in mind that this library is stable, so whatever ends up here can > >>>>>> change in the future. > >>>>>> > >>>>>> This is not saying the following code is problematic. It is just a > >>>>>> general FYI. > >>>>>> > >>>>>> Obviously the toolstack side is going to follow the hypervisor > >>>>>> interface, so I will do a detailed review later. > >>>>> > >>>>> Sure. If the hypervisor interface settles down, we can inform you. > >>>>> > >>>>>> > >>>>>>> +int xendevicemodel_viommu_destroy( > >>>>>>> + xendevicemodel_handle *dmod, domid_t dom, uint32_t > >> viommu_id); > >>>>>>> #endif /* __XEN_TOOLS__ */ > >>>>>>> > >>>>>>> #endif /* XENDEVICEMODEL_H */ > >>>>>>> diff --git a/tools/libs/devicemodel/libxendevicemodel.map > >>>>> b/tools/libs/devicemodel/libxendevicemodel.map > >>>>>>> index 45c773e..c2e0968 100644 > >>>>>>> --- a/tools/libs/devicemodel/libxendevicemodel.map > >>>>>>> +++ b/tools/libs/devicemodel/libxendevicemodel.map > >>>>>>> @@ -17,6 +17,9 @@ VERS_1.0 { > >>>>>>> xendevicemodel_modified_memory; > >>>>>>> xendevicemodel_set_mem_type; > >>>>>>> xendevicemodel_inject_event; > >>>>>>> + xendevicemodel_viommu_query_cap; > >>>>>>> + xendevicemodel_viommu_create; > >>>>>>> + xendevicemodel_viommu_destroy; > >>>>>>> xendevicemodel_restrict; > >>>>>>> xendevicemodel_close; > >>>>>> > >>>>>> I suppose this series is going to miss 4.9. > >>>>>> > >>>>>> Please add these functions to VERS_1.1. > >>>>> > >>>>> Yes. We will fix this. > >>>>> > >>>>>> > >>>>>>> local: *; /* Do not expose anything by default */ > >>>>>>> diff --git a/tools/libxc/include/xenctrl_compat.h > >>>>> b/tools/libxc/include/xenctrl_compat.h > >>>>>>> index 040e7b2..315c45d 100644 > >>>>>>> --- a/tools/libxc/include/xenctrl_compat.h > >>>>>>> +++ b/tools/libxc/include/xenctrl_compat.h > >>>>>>> @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( > >>>>>>> int xc_hvm_inject_trap( > >>>>>>> xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, > >>>>>>> uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t > cr2); > >>>>>>> +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, > >> uint64_t > >>>>> *cap); > >>>>>>> +int xc_viommu_create( > >>>>>>> + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t > >> cap, > >>>>>>> + uint32_t *viommu_id); > >>>>>>> +int xc_viommu_destroy(xc_interface *xch, domid_t dom, > uint32_t > >>>>> viommu_id); > >>>>>>> > >>>>>>> #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ > >>>>>>> > >>>>>>> diff --git a/tools/libxc/xc_devicemodel_compat.c > >>>>> b/tools/libxc/xc_devicemodel_compat.c > >>>>>>> index e4edeea..62f703a 100644 > >>>>>>> --- a/tools/libxc/xc_devicemodel_compat.c > >>>>>>> +++ b/tools/libxc/xc_devicemodel_compat.c > >>>>>> > >>>>>> I don't think you need to provide compat wrappers for them. They > are > >> new > >>>>>> APIs. > >>>>> > >>>>> OK. Got it. > >>>>> > >>>>> Thanks, > >>>>> Chao > >>>>>> > >>>>>> Wei. > >>>>> > >>>>> _______________________________________________ > >>>>> Xen-devel mailing list > >>>>> Xen-devel@lists.xen.org > >>>>> https://lists.xen.org/xen-devel > > > -- > Best regards > Tianyu Lan
On 2017年04月18日 22:15, Paul Durrant wrote: >> -----Original Message----- > [snip] >>> > > >>> > > Not quite sure I understand this. The QEMu device model does not 'pass >> > DMA requests' as such, it maps guest RAM and reads or writes to emulate >> > DMA, right? So, what's needed is a mechanism to map guest RAM by 'bus >> > address'... i.e. an address that will need to be translated through the >> > vIOMMU mappings. This is just an evolution of the current 'priv mapping' >> > operations that allow guest RAM to be mapped by guest physical address. So >> > you don't need a vIOMMU 'device model' as such, do you? >> > >> > >> > Guest also may enable DMA protection mechanism in linux kernel which >> > limits address space of emulated device and this depends on the vIOMMU's >> > DMA translation function. In vIOMMU's MMIO emulation part is in the Xen >> > hypersior and the guest shadow IO page table will be only in the >> > hypervisor. To translate emulated device's DMA request. It's necessary >> > to pass the DMA request to hypervisor. >> > > What do you mean by DMA request though? Are you intending to make some form of hypercall to read or write guest memory? If so then why not introduce a call to map the guest memory (via bus address) and read or write directly. Such "DMA request" in Qemu vIOMMU framework just contains IOVA(IO virtual address) and write/read flag. vIOMMU device model just translates IOVA to GPA and then return back to vIOMMU core which will be in charge of memory access. So hyercall we want to introduce is to translate IOVA to GPA. The data to write and target address to store read data aren't passed to vIOMMU device model and we can't perform read/write directly there. >> > So far we don't support DMA translation and so doesn't pass DMA request. >> > > Indeed. We map guest memory using guest physical address because, without an emulated IOMMU, guest physical address === bus address. This is why I suggest a new mapping operation rather than 'passing a DMA request' to the hypervisor. > >> > Map/umap guest memory already support in Qemu and just like emulated >> > device model access guest memory. Qemu also provides vIOMMU hook to >> > receive DMA request and return target guest address. vIOMMU framework >> > will read/write target address. > That's the part I don't get... why have the vIOMMU code do the reads and writes? Why not have it provide a mapping function and then have the device model in QEMU read and write directly as it does now? > Actually it's common interface in Qemu to read/write guest memory. The code will check whether there is a vIOMMU translation callback or not before performing read/write. If yes, call the callback and vIOMMU device model translate IOVA to GPA and then do read/write operation. >> > What we need to do is to translate DMA >> > request to target address according shadow IO page table in the hypervisor. >> > > Yes, so the mapping has to be done by the hypervisor (as is the case for priv mapping or grant mapping) but the memory accesses themselves can be done directly by the device model in QEMU. Yes. > >> > >> > >>> > > >>>> > >> Qemu is required to use DMOP hypercall and >>>> > >> tool stack may use domctl hyercall. vIOMMU hypercalls will be divided >>>> > >> into two part. >>>> > >> >>>> > >> Domctl: >>>> > >> create, destroy and query. >>>> > >> DMOP: >>>> > >> vDev's DMA related operations. >>> > > >>> > > Yes, the mapping/unmapping operations should be DMOPs and IMO >> > should be designed such that they can be unified with replacements for >> > current 'priv map' ops such that QEMU can use the same function call, but >> > with different address space identifiers (i.e. bus address, guest physical >> > address, etc.). BTW, I say 'etc.' because we should also consider mapping the >> > ioreq pages from Xen using the same call - with a dedicated address space >> > identifier - as well. >>> > > >> > >> > So you agree to divide vIOMMU's hypercalls into two parts(DMOP and >> > Domctl), right? >> > > Yes, I agree with the logic of the split. > > Cheers, > > Paul >
On 2017年05月11日 20:35, Wei Liu wrote: > On Mon, Apr 17, 2017 at 08:01:56PM +0800, Lan Tianyu wrote: >> On 2017年04月17日 19:08, Wei Liu wrote: >>> On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote: >>>> Hi Paul: >>>> Sorry for later response. >>>> >>>> On 3/31/2017 3:57 AM, Chao Gao wrote: >>>>> On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: >>>>>>> -----Original Message----- >>>>>>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of >>>>>>> Chao Gao >>>>>>> Sent: 29 March 2017 01:40 >>>>>>> To: Wei Liu <wei.liu2@citrix.com> >>>>>>> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; >>>>>>> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org >>>>>>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu >>>>>>> operations in libxc >>>>>>> >>>>>>> Tianyu is on vacation this two weeks, so I will try to address >>>>>>> some comments on this series. >>>>>>> >>>>>>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: >>>>>>>> On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: >>>>>>>>> From: Chao Gao <chao.gao@intel.com> >>>>>>>>> >>>>>>>>> In previous patch, we introduce a common vIOMMU layer. In our design, >>>>>>>>> we create/destroy vIOMMU through DMOP interface instead of creating >>>>>>> it >>>>>>>>> according to a config flag of domain. It makes it is possible >>>>>>>>> to create vIOMMU in device model or in tool stack. >>>>>>>>> >>>>>> >>>>>> I've not been following this closely so apologies if this has already been asked... >>>>>> >>>>>> Why would you need to create a vIOMMU instance in an external device model. >>>>>> Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? >>>>> >>>>> I assume your question is why we don't create a vIOMMU instance via hypercall in toolstack. >>>>> I think creating in toolstack is also ok and is easier to be reused by pvh. >>>>> >>>>> If Tianyu has no concern about this, will move this part to toolstack. >>>> >>>> We can move create/destroy vIOMMU in the tool stack but we still need to add >>>> such dummy vIOMMU device model in Qemu to pass virtual device's DMA request >>>> into Xen hypervisor. Qemu is required to use DMOP hypercall and tool stack >>>> may use domctl hyercall. vIOMMU hypercalls will be divided into two part. >>>> >>>> Domctl: >>>> create, destroy and query. >>>> DMOP: >>>> vDev's DMA related operations. >>>> >>>> Is this OK? >>>> >>> >>> Why are they divided into two libraries? Can't they be in DMOP at the >>> same time? >> >> Yes, we can use DMOP for all vIOMMU hyercalls if it's necessary to keep >> unified vIOMMU hyercall type. In theory, DMOP dedicates to be used by >> Qemu but we also can use it in tool stack. If we move create, destroy >> and query operation to tool stack, it isn't necessary to use DMOP for >> them since only tool stack will call them. This is why I said we could >> use domctl for these operations. Both two ways will not affect function >> implementation. Which one it's better from your view? :) >> > > > After reading the subthread I think I agree with Paul. I.e. please > separate them. > Sure. Will update.
On Mon, Apr 17, 2017 at 08:01:56PM +0800, Lan Tianyu wrote: > On 2017年04月17日 19:08, Wei Liu wrote: > > On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote: > >> Hi Paul: > >> Sorry for later response. > >> > >> On 3/31/2017 3:57 AM, Chao Gao wrote: > >>> On Wed, Mar 29, 2017 at 09:08:06AM +0000, Paul Durrant wrote: > >>>>> -----Original Message----- > >>>>> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of > >>>>> Chao Gao > >>>>> Sent: 29 March 2017 01:40 > >>>>> To: Wei Liu <wei.liu2@citrix.com> > >>>>> Cc: Lan Tianyu <tianyu.lan@intel.com>; Kevin Tian <kevin.tian@intel.com>; > >>>>> Ian Jackson <Ian.Jackson@citrix.com>; xen-devel@lists.xen.org > >>>>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu > >>>>> operations in libxc > >>>>> > >>>>> Tianyu is on vacation this two weeks, so I will try to address > >>>>> some comments on this series. > >>>>> > >>>>> On Tue, Mar 28, 2017 at 05:24:03PM +0100, Wei Liu wrote: > >>>>>> On Fri, Mar 17, 2017 at 07:27:05PM +0800, Lan Tianyu wrote: > >>>>>>> From: Chao Gao <chao.gao@intel.com> > >>>>>>> > >>>>>>> In previous patch, we introduce a common vIOMMU layer. In our design, > >>>>>>> we create/destroy vIOMMU through DMOP interface instead of creating > >>>>> it > >>>>>>> according to a config flag of domain. It makes it is possible > >>>>>>> to create vIOMMU in device model or in tool stack. > >>>>>>> > >>>> > >>>> I've not been following this closely so apologies if this has already been asked... > >>>> > >>>> Why would you need to create a vIOMMU instance in an external device model. > >>>> Since the toolstack should be in control of the device model configuration why would it not know in advance that one was required? > >>> > >>> I assume your question is why we don't create a vIOMMU instance via hypercall in toolstack. > >>> I think creating in toolstack is also ok and is easier to be reused by pvh. > >>> > >>> If Tianyu has no concern about this, will move this part to toolstack. > >> > >> We can move create/destroy vIOMMU in the tool stack but we still need to add > >> such dummy vIOMMU device model in Qemu to pass virtual device's DMA request > >> into Xen hypervisor. Qemu is required to use DMOP hypercall and tool stack > >> may use domctl hyercall. vIOMMU hypercalls will be divided into two part. > >> > >> Domctl: > >> create, destroy and query. > >> DMOP: > >> vDev's DMA related operations. > >> > >> Is this OK? > >> > > > > Why are they divided into two libraries? Can't they be in DMOP at the > > same time? > > Yes, we can use DMOP for all vIOMMU hyercalls if it's necessary to keep > unified vIOMMU hyercall type. In theory, DMOP dedicates to be used by > Qemu but we also can use it in tool stack. If we move create, destroy > and query operation to tool stack, it isn't necessary to use DMOP for > them since only tool stack will call them. This is why I said we could > use domctl for these operations. Both two ways will not affect function > implementation. Which one it's better from your view? :) > After reading the subthread I think I agree with Paul. I.e. please separate them.
diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c index a85cb49..aee1150 100644 --- a/tools/libs/devicemodel/core.c +++ b/tools/libs/devicemodel/core.c @@ -498,6 +498,75 @@ int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid) return osdep_xendevicemodel_restrict(dmod, domid); } +int xendevicemodel_viommu_query_cap( + xendevicemodel_handle *dmod, domid_t dom, uint64_t *cap) +{ + struct xen_dm_op op; + struct xen_dm_op_query_viommu_caps *data; + int rc; + + if ( !cap ) + return -EINVAL; + + memset(&op, 0, sizeof(op)); + + op.op = XEN_DMOP_query_viommu_caps; + data = &op.u.query_viommu_caps; + + rc = xendevicemodel_op(dmod, dom, 1, &op, sizeof(op)); + if ( rc ) + return rc; + + *cap = data->caps; + return 0; +} + +int xendevicemodel_viommu_create( + xendevicemodel_handle *dmod, domid_t dom, uint64_t base_addr, + uint64_t cap, uint32_t *viommu_id) +{ + struct xen_dm_op op; + struct xen_dm_op_create_viommu *data; + int rc; + + if ( !viommu_id ) + return -EINVAL; + + memset(&op, 0, sizeof(op)); + + op.op = XEN_DMOP_create_viommu; + data = &op.u.create_viommu; + + data->base_address = base_addr; + data->capabilities = cap; + + rc = xendevicemodel_op(dmod, dom, 1, &op, sizeof(op)); + if ( rc ) + return rc; + + *viommu_id = data->viommu_id; + return 0; +} + +int xendevicemodel_viommu_destroy( + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id) +{ + struct xen_dm_op op; + struct xen_dm_op_destroy_viommu *data; + + if ( !viommu_id ) + return -EINVAL; + + memset(&op, 0, sizeof(op)); + + op.op = XEN_DMOP_destroy_viommu; + data = &op.u.destroy_viommu; + + data->viommu_id = viommu_id; + + return xendevicemodel_op(dmod, dom, 1, &op, sizeof(op)); +} + /* * Local variables: * mode: C diff --git a/tools/libs/devicemodel/include/xendevicemodel.h b/tools/libs/devicemodel/include/xendevicemodel.h index b3f600e..e133dd5 100644 --- a/tools/libs/devicemodel/include/xendevicemodel.h +++ b/tools/libs/devicemodel/include/xendevicemodel.h @@ -293,6 +293,41 @@ int xendevicemodel_inject_event( */ int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid); +/** + * This function queries the capabilitites of vIOMMU emulated by Xen. + * + * @parm dmod a handle to an open devicemodel interface. + * @parm dom the domain id to be serviced. + * @parm cap points to memory to store the capability. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_viommu_query_cap( + xendevicemodel_handle *dmod, domid_t dom, uint64_t *cap); + +/** + * This function creates vIOMMU in Xen hypervisor with base_addr, capability. + * + * @parm dmod a handle to an open devicemodel interface. + * @parm dom the domain id to be serviced. + * @parm base_addr base address of register set of the vIOMMU. + * @parm cap the capability owned by the vIOMMU to be created. + * @parm viommu_id points to memory to store the vIOMMU id. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_viommu_create( + xendevicemodel_handle *dmod, domid_t dom, uint64_t base_addr, + uint64_t cap, uint32_t *viommu_id); + +/** + * This function destroies vIOMMU specified by viommu_id. + * + * @parm dmod a handle to an open devicemodel interface. + * @parm dom the domain id to be serviced. + * @parm viommu_id spcifies the id of the vIOMMU to be destroied. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_viommu_destroy( + xendevicemodel_handle *dmod, domid_t dom, uint32_t viommu_id); #endif /* __XEN_TOOLS__ */ #endif /* XENDEVICEMODEL_H */ diff --git a/tools/libs/devicemodel/libxendevicemodel.map b/tools/libs/devicemodel/libxendevicemodel.map index 45c773e..c2e0968 100644 --- a/tools/libs/devicemodel/libxendevicemodel.map +++ b/tools/libs/devicemodel/libxendevicemodel.map @@ -17,6 +17,9 @@ VERS_1.0 { xendevicemodel_modified_memory; xendevicemodel_set_mem_type; xendevicemodel_inject_event; + xendevicemodel_viommu_query_cap; + xendevicemodel_viommu_create; + xendevicemodel_viommu_destroy; xendevicemodel_restrict; xendevicemodel_close; local: *; /* Do not expose anything by default */ diff --git a/tools/libxc/include/xenctrl_compat.h b/tools/libxc/include/xenctrl_compat.h index 040e7b2..315c45d 100644 --- a/tools/libxc/include/xenctrl_compat.h +++ b/tools/libxc/include/xenctrl_compat.h @@ -164,6 +164,11 @@ int xc_hvm_set_mem_type( int xc_hvm_inject_trap( xc_interface *xch, domid_t domid, int vcpu, uint8_t vector, uint8_t type, uint32_t error_code, uint8_t insn_len, uint64_t cr2); +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t *cap); +int xc_viommu_create( + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, + uint32_t *viommu_id); +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t viommu_id); #endif /* XC_WANT_COMPAT_DEVICEMODEL_API */ diff --git a/tools/libxc/xc_devicemodel_compat.c b/tools/libxc/xc_devicemodel_compat.c index e4edeea..62f703a 100644 --- a/tools/libxc/xc_devicemodel_compat.c +++ b/tools/libxc/xc_devicemodel_compat.c @@ -128,6 +128,24 @@ int xc_hvm_inject_trap( type, error_code, insn_len, cr2); } +int xc_viommu_query_cap(xc_interface *xch, domid_t dom, uint64_t *cap) +{ + return xendevicemodel_viommu_query_cap(xch->dmod, dom, cap); +} + +int xc_viommu_create( + xc_interface *xch, domid_t dom, uint64_t base_addr, uint64_t cap, + uint32_t *viommu_id) +{ + return xendevicemodel_viommu_create(xch->dmod, dom, base_addr, cap, + viommu_id); +} + +int xc_viommu_destroy(xc_interface *xch, domid_t dom, uint32_t viommu_id) +{ + return xendevicemodel_viommu_destroy(xch->dmod, dom, viommu_id); +} + /* * Local variables: * mode: C