| Message ID | 1377701263-3319-19-git-send-email-julien.grall@linaro.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Wed, 2013-08-28 at 15:47 +0100, Julien Grall wrote: > Linux should cope with 'status = "disabled"' in the Device Tree. This is devices which were disabled in the DT passed to Xen, rather than ones which we have disabled ourselves (e.g. the previous patch)? > This solution can be used later to pass-through device to a specific guest. How? I thought disabled meant "not present/wired-up on this variant of the platform"? A user cannot be expected to edit the host DTB to enable passthrough. We might want a dtb_hide cmdline option, or to do it dynamically like pciback is capable of. Or maybe I'm wrong above and this is indeed devices we have disabled ourselves? > > Signed-off-by: Julien Grall <julien.grall@linaro.org> > > --- > Changes in v2: > - Add a comment > --- > xen/arch/arm/domain_build.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c > index d56bc70a..11f247b 100644 > --- a/xen/arch/arm/domain_build.c > +++ b/xen/arch/arm/domain_build.c > @@ -416,9 +416,13 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo, > * - Device used by Xen: Obviously dom0 can't use them > * - Memory: the guest will see a different view of memory. It will > * be allocated later. > + * - Disabled device: Linux is able to cope with status="disabled" > + * property. Therefore these device doesn't need to be mapped. This > + * solution can be use later for pass through. > */ > if ( dt_device_used_by(np) != DOMID_XEN && > - !dt_device_type_is_equal(np, "memory") ) > + !dt_device_type_is_equal(np, "memory") && > + dt_device_is_available(np) ) > { > res = map_device(d, np); >
On 09/09/2013 12:40 PM, Ian Campbell wrote: > On Wed, 2013-08-28 at 15:47 +0100, Julien Grall wrote: >> Linux should cope with 'status = "disabled"' in the Device Tree. > > This is devices which were disabled in the DT passed to Xen, rather than > ones which we have disabled ourselves (e.g. the previous patch)? Yes. >> This solution can be used later to pass-through device to a specific guest. > > How? I thought disabled meant "not present/wired-up on this variant of > the platform"? A user cannot be expected to edit the host DTB to enable > passthrough. We might want a dtb_hide cmdline option, or to do it > dynamically like pciback is capable of. Disabled also means "the device is not presently operational, but it might become operational in the future". > Or maybe I'm wrong above and this is indeed devices we have disabled > ourselves? I'm not sure it's usefull. But I don't see any reason to map disabled device in dom0. >> >> Signed-off-by: Julien Grall <julien.grall@linaro.org> >> >> --- >> Changes in v2: >> - Add a comment >> --- >> xen/arch/arm/domain_build.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index d56bc70a..11f247b 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -416,9 +416,13 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo, >> * - Device used by Xen: Obviously dom0 can't use them >> * - Memory: the guest will see a different view of memory. It will >> * be allocated later. >> + * - Disabled device: Linux is able to cope with status="disabled" >> + * property. Therefore these device doesn't need to be mapped. This >> + * solution can be use later for pass through. >> */ >> if ( dt_device_used_by(np) != DOMID_XEN && >> - !dt_device_type_is_equal(np, "memory") ) >> + !dt_device_type_is_equal(np, "memory") && >> + dt_device_is_available(np) ) >> { >> res = map_device(d, np); >> > >
On Mon, 2013-09-09 at 22:59 +0100, Julien Grall wrote: > On 09/09/2013 12:40 PM, Ian Campbell wrote: > > On Wed, 2013-08-28 at 15:47 +0100, Julien Grall wrote: > >> Linux should cope with 'status = "disabled"' in the Device Tree. > > > > This is devices which were disabled in the DT passed to Xen, rather than > > ones which we have disabled ourselves (e.g. the previous patch)? > > Yes. > > > >> This solution can be used later to pass-through device to a specific guest. > > > > How? I thought disabled meant "not present/wired-up on this variant of > > the platform"? A user cannot be expected to edit the host DTB to enable > > passthrough. We might want a dtb_hide cmdline option, or to do it > > dynamically like pciback is capable of. > > Disabled also means "the device is not presently operational, but it > might become operational in the future". > > > Or maybe I'm wrong above and this is indeed devices we have disabled > > ourselves? > > I'm not sure it's usefull. But I don't see any reason to map disabled > device in dom0. Agreed, I just think the reference to passthrough in the changelog is not relevant to this and might not be accurate. Ian.
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index d56bc70a..11f247b 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -416,9 +416,13 @@ static int handle_node(struct domain *d, struct kernel_info *kinfo, * - Device used by Xen: Obviously dom0 can't use them * - Memory: the guest will see a different view of memory. It will * be allocated later. + * - Disabled device: Linux is able to cope with status="disabled" + * property. Therefore these device doesn't need to be mapped. This + * solution can be use later for pass through. */ if ( dt_device_used_by(np) != DOMID_XEN && - !dt_device_type_is_equal(np, "memory") ) + !dt_device_type_is_equal(np, "memory") && + dt_device_is_available(np) ) { res = map_device(d, np);
Linux should cope with 'status = "disabled"' in the Device Tree. This solution can be used later to pass-through device to a specific guest. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- Changes in v2: - Add a comment --- xen/arch/arm/domain_build.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)