Re: VIRTIO_F_IOMMU_PLATFORM
On Tue, Sep 27, 2016 at 09:57:14AM +0100, Will Deacon wrote: > Hi Michael, > > In commit 1a937693993f ("virtio: new feature to detect IOMMU device quirk"), > you added a new feature bit (VIRTIO_F_IOMMU_PLATFORM) to describe whether > or not a given virtio device requires physical address or bus addresses. > > Is there a plan to get this incorporated into the virtio spec [1]? At the > moment, I can't see a working draft that includes the new bit. Having it > in the spec would help convince implementors that it's not just a Linux > thing. > > Thanks, > > Will > > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html Absolutely. Want to contribute a patch? -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] VMCI: Doorbell create and destroy fixes
This change consists of two changes: 1) If vmci_doorbell_create is called when neither guest nor host personality as been initialized, vmci_get_context_id will return VMCI_INVALID_ID. In that case, we should fail the create call. 2) In doorbell destroy, we assume that vmci_guest_code_active() has the same return value on create and destroy. That may not be the case, so we may end up with the wrong refcount. Instead, destroy should check explicitly whether the doorbell is in the index table as an indicator of whether the guest code was active at create time. Reviewed-by: Adit Ranadive Signed-off-by: Jorgen Hansen --- drivers/misc/vmw_vmci/vmci_doorbell.c |8 +++- drivers/misc/vmw_vmci/vmci_driver.c |2 +- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/misc/vmw_vmci/vmci_doorbell.c b/drivers/misc/vmw_vmci/vmci_doorbell.c index a8cee33..b3fa738 100644 --- a/drivers/misc/vmw_vmci/vmci_doorbell.c +++ b/drivers/misc/vmw_vmci/vmci_doorbell.c @@ -431,6 +431,12 @@ int vmci_doorbell_create(struct vmci_handle *handle, if (vmci_handle_is_invalid(*handle)) { u32 context_id = vmci_get_context_id(); + if (context_id == VMCI_INVALID_ID) { + pr_warn("Failed to get context ID\n"); + result = VMCI_ERROR_NO_RESOURCES; + goto free_mem; + } + /* Let resource code allocate a free ID for us */ new_handle = vmci_make_handle(context_id, VMCI_INVALID_ID); } else { @@ -525,7 +531,7 @@ int vmci_doorbell_destroy(struct vmci_handle handle) entry = container_of(resource, struct dbell_entry, resource); - if (vmci_guest_code_active()) { + if (!hlist_unhashed(&entry->node)) { int result; dbell_index_table_remove(entry); diff --git a/drivers/misc/vmw_vmci/vmci_driver.c b/drivers/misc/vmw_vmci/vmci_driver.c index 896be15..d7eaf1e 100644 --- a/drivers/misc/vmw_vmci/vmci_driver.c +++ b/drivers/misc/vmw_vmci/vmci_driver.c @@ -113,5 +113,5 @@ module_exit(vmci_drv_exit); MODULE_AUTHOR("VMware, Inc."); MODULE_DESCRIPTION("VMware Virtual Machine Communication Interface."); -MODULE_VERSION("1.1.4.0-k"); +MODULE_VERSION("1.1.5.0-k"); MODULE_LICENSE("GPL v2"); -- 1.7.0 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Hi Peter, On 6 October 2016 at 11:48, Peter Griffin wrote: > Hi Emil, > > On Wed, 21 Sep 2016, Emil Velikov wrote: > >> On 20 September 2016 at 09:32, Peter Griffin >> wrote: >> > Hi Emil, >> > >> > On Tue, 20 Sep 2016, Emil Velikov wrote: >> > >> >> On 5 September 2016 at 14:16, Peter Griffin >> >> wrote: >> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following >> >> > recursive dependency. >> > >> > >> >> > >> >> From a humble skim through remoteproc, drm and a few other subsystems >> >> I think the above is wrong. All the drivers (outside of remoteproc), >> >> that I've seen, depend on the core component, they don't select it. >> > >> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and >> > why it is like it is. >> > >> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with >> > all >> > the other drivers in the remoteproc subsystem which has exposed this >> > recursive >> > dependency issue. >> > >> > For this particular kconfig symbol a quick grep reveals more drivers in >> > the kernel using 'select', than 'depend on' >> > >> > git grep "select VIRTIO" | wc -l >> > 14 >> > >> > git grep "depends on VIRTIO" | wc -l >> > 10 >> > >> Might be worth taking a closer look into these at some point. > > VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also > mentions that drivers should select it. > This is a (un)fortunate detail cannot/should not overrule the other arguments I've mentioned, should it ? >> >> > >> >> Furthermore most places explicitly hide the drivers from the menu if >> >> the core component isn't enabled. >> > >> > Remoteproc subsystem takes a different approach, the core code is only >> > enabled >> > if a driver which relies on it is enabled. This IMHO makes sense, as >> > remoteproc is not widely used (only a few particular ARM SoC's). >> > >> > It is true that for subsystems which rely on the core component being >> > explicitly enabled, they often tend to hide drivers which depend on it >> > from the menu unless it is. This also makes sense. >> > >> >> >> >> Is there something that requires such a different/unusual behaviour in >> >> remoteproc ? >> >> >> > >> > I'm not sure it is that unusual...looking at config USB, it selects >> > USB_COMMON in >> > mfd subsystem, client drivers select MFD_CORE. >> > >> On the USB case I'm not sure what the reasoning behind the USB vs >> USB_COMMON split. In seems that one could just fold them, but that's >> another topic. On the MFD side... it follows the select {,mis,ab}use. >> With one (the only one?) MFD driver not using/selecting MFD_CORE doing >> it's own version of mfd_add_devices... which could be reworked, >> possibly. > > Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol > with no dependencies so it matches the documentation Jani referenced. > > I personally think the approach taken makes sense, as why would you want to > have > a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device > which uses it also enabled in your kernel? > > It seems to me a good solution to make the client drivers select the core > component so that it only gets enabled if at least one driver requires it. > This avoids having useless core code which will never be used compiled into > the > kernel and in the end a smaller kernel size for a given kernel configuration > (better > cache use etc etc). > >> > I've added Arnd to this thread, as I've seen lots of Kconfig patches from >> > him >> > recently, maybe he has some thoughts on whether this is the correct fix or >> > not? >> > >> Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty >> reasonable, but it'll be great to hear others as well. > > Yes me to. However I don't think anything in this patch is at odds with the > documentation Jani has referenced. > It case it's not clear, let me elaborate: Yes, using depend might not be the most user-friendly thing to do and in the long term we might want to move to select. Yes, I agree with the argument about symbol visibility but that is not the only contributing factor. If one wants to pick on specific users which opt for $driver select $core they must do the same for $driver depends on $core. Check the number 'in favour" of each case and draw their conclusions ;-) In particular: both MFD_CORE and USB_COMMON, are _optional_ as only some drivers depends on them. Thus giving them as an example is wrong/irrelevant, I'm afraid. Thanks Emil ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Hi Emil, On Wed, 21 Sep 2016, Emil Velikov wrote: > On 20 September 2016 at 09:32, Peter Griffin wrote: > > Hi Emil, > > > > On Tue, 20 Sep 2016, Emil Velikov wrote: > > > >> On 5 September 2016 at 14:16, Peter Griffin > >> wrote: > >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following > >> > recursive dependency. > > > > > >> > > >> From a humble skim through remoteproc, drm and a few other subsystems > >> I think the above is wrong. All the drivers (outside of remoteproc), > >> that I've seen, depend on the core component, they don't select it. > > > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > > why it is like it is. > > > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with > > all > > the other drivers in the remoteproc subsystem which has exposed this > > recursive > > dependency issue. > > > > For this particular kconfig symbol a quick grep reveals more drivers in > > the kernel using 'select', than 'depend on' > > > > git grep "select VIRTIO" | wc -l > > 14 > > > > git grep "depends on VIRTIO" | wc -l > > 10 > > > Might be worth taking a closer look into these at some point. VIRTIO has no dependencies, and is a non visible symbol. Its Kconfig help also mentions that drivers should select it. > > > > >> Furthermore most places explicitly hide the drivers from the menu if > >> the core component isn't enabled. > > > > Remoteproc subsystem takes a different approach, the core code is only > > enabled > > if a driver which relies on it is enabled. This IMHO makes sense, as > > remoteproc is not widely used (only a few particular ARM SoC's). > > > > It is true that for subsystems which rely on the core component being > > explicitly enabled, they often tend to hide drivers which depend on it > > from the menu unless it is. This also makes sense. > > > >> > >> Is there something that requires such a different/unusual behaviour in > >> remoteproc ? > >> > > > > I'm not sure it is that unusual...looking at config USB, it selects > > USB_COMMON in > > mfd subsystem, client drivers select MFD_CORE. > > > On the USB case I'm not sure what the reasoning behind the USB vs > USB_COMMON split. In seems that one could just fold them, but that's > another topic. On the MFD side... it follows the select {,mis,ab}use. > With one (the only one?) MFD driver not using/selecting MFD_CORE doing > it's own version of mfd_add_devices... which could be reworked, > possibly. Much like selecting VIRTIO in this patch, MFD_CORE is a non visible symbol with no dependencies so it matches the documentation Jani referenced. I personally think the approach taken makes sense, as why would you want to have a CONFIG_MFD_CORE=y symbol being enabled unless you actually have a MFD device which uses it also enabled in your kernel? It seems to me a good solution to make the client drivers select the core component so that it only gets enabled if at least one driver requires it. This avoids having useless core code which will never be used compiled into the kernel and in the end a smaller kernel size for a given kernel configuration (better cache use etc etc). > > I've added Arnd to this thread, as I've seen lots of Kconfig patches from > > him > > recently, maybe he has some thoughts on whether this is the correct fix or > > not? > > > Ack. Fwiw, I believe that the reasoning put by Jani is perfeclty > reasonable, but it'll be great to hear others as well. Yes me to. However I don't think anything in this patch is at odds with the documentation Jani has referenced. regards, Peter. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
On 6 October 2016 at 10:37, Peter Griffin wrote: > In fact the help text for VIRTIO even states this option should be selected > by any driver which implements virtio. > Almost but not quite. It says: "This option is selected by any driver which implements the virtio _bus_" REMOTEPROC obviously does that while the ST SLIM driver does not. Thus the latter should _not_ select, be that explicitly or implicitly via REMOTEPROC, the symbol. >> >> People tend to abuse select because it's "convenient". If you depend, >> but some of your dependencies aren't met, you're in for some digging >> through Kconfig to find the missing deps. Just to make the option you >> want visible in menuconfig. If you instead select something with >> dependencies, it'll be right most of the time, and it's "convenient", >> until it breaks. (And hey, it usually breaks for someone else with some >> other config, so it's still convenient for you.) > > I'm sure they do but in this case it is actually the use of 'depends on' > which has caused the breakage and inconvenience for somebody else and sadly > this > inconvienice is still on-going due to this patch not being applied or getting > an > acked-by from the appropriate maintainers. > Surely you're not saying that pre-existing driver following the documentation, is 'causing breakage' for a new driver {ab,mis}using a feature ? This reminds me an old saying: "If the shoe doesn’t fit, it doesn’t mean there is anything wrong with your feet." You seem to be suggesting the opposite ? >> >> Perhaps kconfig should complain about selecting visible symbols and >> symbols with dependencies. > > That sounds like it would be a useful addition. > > Is it possible to get this patch applied or an acked-by to avoid further delay > to the fdma series? > Please don't apply duct tape, especially where it's _not_ needed. $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig ... will resolve things in the right place. The alternative will lead to random issues in other subsystems. Regards, Emil ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Hi Bjorn, On 27 September 2016 at 18:01, Bjorn Andersson wrote: > On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote: > >> On 20 September 2016 at 09:32, Peter Griffin >> wrote: >> > Hi Emil, >> > >> > On Tue, 20 Sep 2016, Emil Velikov wrote: >> > >> >> On 5 September 2016 at 14:16, Peter Griffin >> >> wrote: >> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following >> >> > recursive dependency. >> > >> > >> >> > >> >> From a humble skim through remoteproc, drm and a few other subsystems >> >> I think the above is wrong. All the drivers (outside of remoteproc), >> >> that I've seen, depend on the core component, they don't select it. >> > >> > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and >> > why it is like it is. >> > >> > For this particular SLIM_RPROC I have added it to Kconfig in keeping with >> > all >> > the other drivers in the remoteproc subsystem which has exposed this >> > recursive >> > dependency issue. >> > >> > For this particular kconfig symbol a quick grep reveals more drivers in >> > the kernel using 'select', than 'depend on' >> > >> > git grep "select VIRTIO" | wc -l >> > 14 >> > >> > git grep "depends on VIRTIO" | wc -l >> > 10 >> > >> Might be worth taking a closer look into these at some point. >> > > The general idea here is that VIRTIO provides the "framework" and as > such drivers implementing VIRTIO do select and drivers using virtio use > depends. > > This is found in several places around the kernel. > >> > >> >> Furthermore most places explicitly hide the drivers from the menu if >> >> the core component isn't enabled. >> > >> > Remoteproc subsystem takes a different approach, the core code is only >> > enabled >> > if a driver which relies on it is enabled. This IMHO makes sense, as >> > remoteproc is not widely used (only a few particular ARM SoC's). >> > >> > It is true that for subsystems which rely on the core component being >> > explicitly enabled, they often tend to hide drivers which depend on it >> > from the menu unless it is. This also makes sense. >> > >> >> >> >> Is there something that requires such a different/unusual behaviour in >> >> remoteproc ? >> >> > > There's nothing unusual in remoteproc that forces us to stay with this > model; however the parts related to the REMOTEPROC config is useless by > themselves. > I'm afraid that the "supporting" arguments you're using are generic and not specific to remoteproc. Although as Jani mentioned and pointed to the documentation, remoteproc is {mis,ab}using 'select' leading to issues elsewhere. In the long term we might want to switch to 'select' and attribute kconfig like Jani suggested. But in the short term we want to avoid select-ing things just for our "convenience". Thanks Emil ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Hi Jani, Sorry for the delay, I've been travelling last week. On Tue, 20 Sep 2016, Jani Nikula wrote: > On Tue, 20 Sep 2016, Peter Griffin wrote: > > Hi Emil, > > > > On Tue, 20 Sep 2016, Emil Velikov wrote: > > > >> On 5 September 2016 at 14:16, Peter Griffin > >> wrote: > >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following > >> > recursive dependency. > > > > > >> > > >> From a humble skim through remoteproc, drm and a few other subsystems > >> I think the above is wrong. All the drivers (outside of remoteproc), > >> that I've seen, depend on the core component, they don't select it. > > > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > > why it is like it is. > > > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with > > all > > the other drivers in the remoteproc subsystem which has exposed this > > recursive > > dependency issue. > > > > For this particular kconfig symbol a quick grep reveals more drivers in > > the kernel using 'select', than 'depend on' > > > > git grep "select VIRTIO" | wc -l > > 14 > > > > git grep "depends on VIRTIO" | wc -l > > 10 > > > > > >> Furthermore most places explicitly hide the drivers from the menu if > >> the core component isn't enabled. > > > > Remoteproc subsystem takes a different approach, the core code is only > > enabled > > if a driver which relies on it is enabled. This IMHO makes sense, as > > remoteproc is not widely used (only a few particular ARM SoC's). > > > > It is true that for subsystems which rely on the core component being > > explicitly enabled, they often tend to hide drivers which depend on it > > from the menu unless it is. This also makes sense. > > > >> > >> Is there something that requires such a different/unusual behaviour in > >> remoteproc ? > >> > > > > I'm not sure it is that unusual...looking at config USB, it selects > > USB_COMMON in > > mfd subsystem, client drivers select MFD_CORE. > > > > I've added Arnd to this thread, as I've seen lots of Kconfig patches from > > him > > recently, maybe he has some thoughts on whether this is the correct fix or > > not? > > > Documentation/kbuild/kconfig-language.txt: > > Note: > select should be used with care. select will force > a symbol to a value without visiting the dependencies. > By abusing select you are able to select a symbol FOO even > if FOO depends on BAR that is not set. > In general use select only for non-visible symbols > (no prompts anywhere) and for symbols with no dependencies. > That will limit the usefulness but on the other hand avoid > the illegal configurations all over. Thanks for the documentation link. I believe this proves this patch is an appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies. In fact the help text for VIRTIO even states this option should be selected by any driver which implements virtio. > > People tend to abuse select because it's "convenient". If you depend, > but some of your dependencies aren't met, you're in for some digging > through Kconfig to find the missing deps. Just to make the option you > want visible in menuconfig. If you instead select something with > dependencies, it'll be right most of the time, and it's "convenient", > until it breaks. (And hey, it usually breaks for someone else with some > other config, so it's still convenient for you.) I'm sure they do but in this case it is actually the use of 'depends on' which has caused the breakage and inconvenience for somebody else and sadly this inconvienice is still on-going due to this patch not being applied or getting an acked-by from the appropriate maintainers. > > Perhaps kconfig should complain about selecting visible symbols and > symbols with dependencies. That sounds like it would be a useful addition. Is it possible to get this patch applied or an acked-by to avoid further delay to the fdma series? regards, Peter. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization