* [PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure
From: Robin Murphy @ 2016-11-09 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109141948.19244-8-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> Since acpi_dma_configure() is used to configure DMA operations, the
> function initializes the dma/coherent_dma masks to sane default values
> if the current masks are uninitialized (also to keep the default values
> consistent with DT systems) to make sure the device has a complete
> default DMA set-up.
>
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> drivers/pci/probe.c | 3 +--
> include/acpi/acpi_bus.h | 2 ++
> include/linux/acpi.h | 5 +++++
> 5 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 5ea5dc2..f8d6564 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -227,8 +227,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>
> attr = acpi_get_dma_attr(acpi_dev);
> if (attr != DEV_DMA_NOT_SUPPORTED)
> - arch_setup_dma_ops(dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(dev, attr);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> @@ -251,6 +250,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> return 0;
>
> err:
> + acpi_dma_deconfigure(dev);
> ACPI_COMPANION_SET(dev, NULL);
> put_device(dev);
> put_device(&acpi_dev->dev);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 035ac64..694e0b6 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,6 +1370,46 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NON_COHERENT;
> }
>
> +/**
> + * acpi_dma_configure - Set-up DMA configuration for the device.
> + * @dev: The pointer to the device
> + * @attr: device dma attributes
> + */
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +{
> + /*
> + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> + * setup the correct supported mask.
> + */
> + if (!dev->coherent_dma_mask)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> + * Set it to coherent_dma_mask by default if the architecture
> + * code has not set it.
> + */
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + /*
> + * Assume dma valid range starts at 0 and covers the whole
> + * coherent_dma_mask.
> + */
> + arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> + attr == DEV_DMA_COHERENT);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_configure);
> +
> +/**
> + * acpi_dma_deconfigure - Tear-down DMA configuration for the device.
> + * @dev: The pointer to the device
> + */
> +void acpi_dma_deconfigure(struct device *dev)
> +{
> + arch_teardown_dma_ops(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_deconfigure);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ab00267..c29e07a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1738,8 +1738,7 @@ static void pci_dma_configure(struct pci_dev *dev)
> if (attr == DEV_DMA_NOT_SUPPORTED)
> dev_warn(&dev->dev, "DMA not supported.\n");
If we're going to check attr for DMA support before each call like this,
it seems like we may as well put the check at the top of
acpi_dma_configure() instead. I think it should be viable to predicate
the warning on dev_is_pci() at this point, if that's the appropriate
behaviour.
Still, we're likely to be touching this again soon with the
IOMMU-probe-ordering work, so there's plenty of room for further
cleanups then:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> else
> - arch_setup_dma_ops(&dev->dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(&dev->dev, attr);
> }
>
> pci_put_host_bridge_device(bridge);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index c1a524d..4242c31 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,6 +573,8 @@ struct acpi_pci_root {
>
> bool acpi_dma_supported(struct acpi_device *adev);
> enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +void acpi_dma_deconfigure(struct device *dev);
>
> struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> u64 address, bool check_children);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 6efb13c..df961f4 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -764,6 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NOT_SUPPORTED;
> }
>
> +static inline void acpi_dma_configure(struct device *dev,
> + enum dev_dma_attr attr) { }
> +
> +static inline void acpi_dma_deconfigure(struct device *dev) { }
> +
> #define ACPI_PTR(_ptr) (NULL)
>
> static inline void acpi_device_set_enumerated(struct acpi_device *adev)
>
^ permalink raw reply
* Re: [PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure
From: Robin Murphy @ 2016-11-09 15:33 UTC (permalink / raw)
To: Lorenzo Pieralisi, iommu
Cc: linux-arm-kernel, linux-acpi, Marc Zyngier, Tomasz Nowicki,
Joerg Roedel, Rafael J. Wysocki, linux-kernel, Will Deacon,
Sinan Kaya, Eric Auger, linux-pci, Hanjun Guo, Jon Masters,
Bjorn Helgaas, Dennis Chen, Prem Mallappa, Nate Watterson
In-Reply-To: <20161109141948.19244-8-lorenzo.pieralisi@arm.com>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> Since acpi_dma_configure() is used to configure DMA operations, the
> function initializes the dma/coherent_dma masks to sane default values
> if the current masks are uninitialized (also to keep the default values
> consistent with DT systems) to make sure the device has a complete
> default DMA set-up.
>
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [pci]
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Tomasz Nowicki <tn@semihalf.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> drivers/pci/probe.c | 3 +--
> include/acpi/acpi_bus.h | 2 ++
> include/linux/acpi.h | 5 +++++
> 5 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 5ea5dc2..f8d6564 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -227,8 +227,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>
> attr = acpi_get_dma_attr(acpi_dev);
> if (attr != DEV_DMA_NOT_SUPPORTED)
> - arch_setup_dma_ops(dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(dev, attr);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> @@ -251,6 +250,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> return 0;
>
> err:
> + acpi_dma_deconfigure(dev);
> ACPI_COMPANION_SET(dev, NULL);
> put_device(dev);
> put_device(&acpi_dev->dev);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 035ac64..694e0b6 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,6 +1370,46 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NON_COHERENT;
> }
>
> +/**
> + * acpi_dma_configure - Set-up DMA configuration for the device.
> + * @dev: The pointer to the device
> + * @attr: device dma attributes
> + */
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +{
> + /*
> + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> + * setup the correct supported mask.
> + */
> + if (!dev->coherent_dma_mask)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> + * Set it to coherent_dma_mask by default if the architecture
> + * code has not set it.
> + */
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + /*
> + * Assume dma valid range starts at 0 and covers the whole
> + * coherent_dma_mask.
> + */
> + arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> + attr == DEV_DMA_COHERENT);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_configure);
> +
> +/**
> + * acpi_dma_deconfigure - Tear-down DMA configuration for the device.
> + * @dev: The pointer to the device
> + */
> +void acpi_dma_deconfigure(struct device *dev)
> +{
> + arch_teardown_dma_ops(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_deconfigure);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ab00267..c29e07a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1738,8 +1738,7 @@ static void pci_dma_configure(struct pci_dev *dev)
> if (attr == DEV_DMA_NOT_SUPPORTED)
> dev_warn(&dev->dev, "DMA not supported.\n");
If we're going to check attr for DMA support before each call like this,
it seems like we may as well put the check at the top of
acpi_dma_configure() instead. I think it should be viable to predicate
the warning on dev_is_pci() at this point, if that's the appropriate
behaviour.
Still, we're likely to be touching this again soon with the
IOMMU-probe-ordering work, so there's plenty of room for further
cleanups then:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> else
> - arch_setup_dma_ops(&dev->dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(&dev->dev, attr);
> }
>
> pci_put_host_bridge_device(bridge);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index c1a524d..4242c31 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,6 +573,8 @@ struct acpi_pci_root {
>
> bool acpi_dma_supported(struct acpi_device *adev);
> enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +void acpi_dma_deconfigure(struct device *dev);
>
> struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> u64 address, bool check_children);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 6efb13c..df961f4 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -764,6 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NOT_SUPPORTED;
> }
>
> +static inline void acpi_dma_configure(struct device *dev,
> + enum dev_dma_attr attr) { }
> +
> +static inline void acpi_dma_deconfigure(struct device *dev) { }
> +
> #define ACPI_PTR(_ptr) (NULL)
>
> static inline void acpi_device_set_enumerated(struct acpi_device *adev)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure
From: Robin Murphy @ 2016-11-09 15:33 UTC (permalink / raw)
To: Lorenzo Pieralisi,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, Marc Zyngier, Tomasz Nowicki,
Rafael J. Wysocki, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Will Deacon, Sinan Kaya, linux-pci-u79uwXL29TY76Z2rM5mHXA,
Jon Masters, Bjorn Helgaas, Dennis Chen, Prem Mallappa
In-Reply-To: <20161109141948.19244-8-lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
On 09/11/16 14:19, Lorenzo Pieralisi wrote:
> On DT based systems, the of_dma_configure() API implements DMA
> configuration for a given device. On ACPI systems an API equivalent to
> of_dma_configure() is missing which implies that it is currently not
> possible to set-up DMA operations for devices through the ACPI generic
> kernel layer.
>
> This patch fills the gap by introducing acpi_dma_configure/deconfigure()
> calls that for now are just wrappers around arch_setup_dma_ops() and
> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
>
> Since acpi_dma_configure() is used to configure DMA operations, the
> function initializes the dma/coherent_dma masks to sane default values
> if the current masks are uninitialized (also to keep the default values
> consistent with DT systems) to make sure the device has a complete
> default DMA set-up.
>
> The DMA range size passed to arch_setup_dma_ops() is sized according
> to the device coherent_dma_mask (starting at address 0x0), mirroring the
> DT probing path behaviour when a dma-ranges property is not provided
> for the device being probed; this changes the current arch_setup_dma_ops()
> call parameters in the ACPI probing case, but since arch_setup_dma_ops()
> is a NOP on all architectures but ARM/ARM64 this patch does not change
> the current kernel behaviour on them.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> Acked-by: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> [pci]
> Tested-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Tested-by: Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
> Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Cc: Tomasz Nowicki <tn-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
> Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> Cc: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
> ---
> drivers/acpi/glue.c | 4 ++--
> drivers/acpi/scan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> drivers/pci/probe.c | 3 +--
> include/acpi/acpi_bus.h | 2 ++
> include/linux/acpi.h | 5 +++++
> 5 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index 5ea5dc2..f8d6564 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -227,8 +227,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>
> attr = acpi_get_dma_attr(acpi_dev);
> if (attr != DEV_DMA_NOT_SUPPORTED)
> - arch_setup_dma_ops(dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(dev, attr);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> @@ -251,6 +250,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> return 0;
>
> err:
> + acpi_dma_deconfigure(dev);
> ACPI_COMPANION_SET(dev, NULL);
> put_device(dev);
> put_device(&acpi_dev->dev);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 035ac64..694e0b6 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1370,6 +1370,46 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NON_COHERENT;
> }
>
> +/**
> + * acpi_dma_configure - Set-up DMA configuration for the device.
> + * @dev: The pointer to the device
> + * @attr: device dma attributes
> + */
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +{
> + /*
> + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> + * setup the correct supported mask.
> + */
> + if (!dev->coherent_dma_mask)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> + * Set it to coherent_dma_mask by default if the architecture
> + * code has not set it.
> + */
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + /*
> + * Assume dma valid range starts at 0 and covers the whole
> + * coherent_dma_mask.
> + */
> + arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> + attr == DEV_DMA_COHERENT);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_configure);
> +
> +/**
> + * acpi_dma_deconfigure - Tear-down DMA configuration for the device.
> + * @dev: The pointer to the device
> + */
> +void acpi_dma_deconfigure(struct device *dev)
> +{
> + arch_teardown_dma_ops(dev);
> +}
> +EXPORT_SYMBOL_GPL(acpi_dma_deconfigure);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ab00267..c29e07a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1738,8 +1738,7 @@ static void pci_dma_configure(struct pci_dev *dev)
> if (attr == DEV_DMA_NOT_SUPPORTED)
> dev_warn(&dev->dev, "DMA not supported.\n");
If we're going to check attr for DMA support before each call like this,
it seems like we may as well put the check at the top of
acpi_dma_configure() instead. I think it should be viable to predicate
the warning on dev_is_pci() at this point, if that's the appropriate
behaviour.
Still, we're likely to be touching this again soon with the
IOMMU-probe-ordering work, so there's plenty of room for further
cleanups then:
Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> else
> - arch_setup_dma_ops(&dev->dev, 0, 0, NULL,
> - attr == DEV_DMA_COHERENT);
> + acpi_dma_configure(&dev->dev, attr);
> }
>
> pci_put_host_bridge_device(bridge);
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index c1a524d..4242c31 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,6 +573,8 @@ struct acpi_pci_root {
>
> bool acpi_dma_supported(struct acpi_device *adev);
> enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> +void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +void acpi_dma_deconfigure(struct device *dev);
>
> struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> u64 address, bool check_children);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 6efb13c..df961f4 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -764,6 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> return DEV_DMA_NOT_SUPPORTED;
> }
>
> +static inline void acpi_dma_configure(struct device *dev,
> + enum dev_dma_attr attr) { }
> +
> +static inline void acpi_dma_deconfigure(struct device *dev) { }
> +
> #define ACPI_PTR(_ptr) (NULL)
>
> static inline void acpi_device_set_enumerated(struct acpi_device *adev)
>
^ permalink raw reply
* Re: [PATCH] drbd: Fix kernel_sendmsg() usage
From: Lars Ellenberg @ 2016-11-09 15:32 UTC (permalink / raw)
To: Jens Axboe
Cc: Richard Weinberger, wolfgang.glas, christoph.lechleitner,
philipp.reisner, stable, linux-kernel, viro, drbd-dev
In-Reply-To: <20161108165204.GC2834@kernel.dk>
On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote:
> > > This should go into 4.9,
> > > and into all stable branches since and including v4.0,
> > > which is the first to contain the exposing change.
> > >
> > > It is correct for all stable branches older than that as well
> > > (which contain the DRBD driver; which is 2.6.33 and up).
> > >
> > > It requires a small "conflict" resolution for v4.4 and earlier, with v4.5
> > > we dropped the comment block immediately preceding the kernel_sendmsg().
> > >
> > > Cc: stable@vger.kernel.org
> > > Cc: viro@zeniv.linux.org.uk
> > > Cc: christoph.lechleitner@iteg.at
> > > Cc: wolfgang.glas@iteg.at
> > > Reported-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
> > > Tested-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
> > > Signed-off-by: Richard Weinberger <richard@nod.at>
> > > Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
> >
> > Changing my patch is perfectly fine, but please clearly state it.
> > I.e. by adding something like that before your S-o-b.
> > [Lars: Massaged patch to match my personal taste...]
>
> Lars, are you sending a new one? If you do, add the stable tag as well.
So my "change" against his original patch was
- rv = kernel_sendmsg(sock, &msg, &iov, 1, size - sent);
+ rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len);
to make it "more obviously correct" from looking just at the one line
without even having to read the context. And a more verbose commit message.
If that requires yet additional noise, sure, so be it :)
Should I sent two patches, one that applies to 4.5 and later,
and one that applies to 2.6.33 ... 4.4, or are you or stable
willing to resolve the trivial "missing comment block" conflict yourself?
--
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support
DRBD® and LINBIT® are registered trademarks of LINBIT
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-2.8] migration: Fix return code of ram_save_iterate()
From: Dr. David Alan Gilbert @ 2016-11-09 15:32 UTC (permalink / raw)
To: Thomas Huth; +Cc: Amit Shah, Juan Quintela, qemu-devel, David Gibson
In-Reply-To: <9c44c2ec-ff09-8667-f78c-644686eec0ed@redhat.com>
* Thomas Huth (thuth@redhat.com) wrote:
> On 09.11.2016 16:13, Dr. David Alan Gilbert wrote:
> > * Thomas Huth (thuth@redhat.com) wrote:
> >> On 09.11.2016 08:18, Amit Shah wrote:
> >>> On (Fri) 04 Nov 2016 [14:10:17], Thomas Huth wrote:
> >>>> qemu_savevm_state_iterate() expects the iterators to return 1
> >>>> when they are done, and 0 if there is still something left to do.
> >>>> However, ram_save_iterate() does not obey this rule and returns
> >>>> the number of saved pages instead. This causes a fatal hang with
> >>>> ppc64 guests when you run QEMU like this (also works with TCG):
> >>>
> >>> "works with" -- does that mean reproduces with?
> >>
> >> Yes, that's what I've meant: You can reproduce it with TCG (e.g. running
> >> on a x86 system), too, there's no need for a real POWER machine with KVM
> >> here.
> >
> > How did you trigger it on x86?
>
> As described below - qemu-img + qemu-system-ppc64 + savevm is enough to
> trigger it on a x86 host.
Oh OK; so yes still ppc64 target.
Dave
> >
> >>>> qemu-img create -f qcow2 /tmp/test.qcow2 1M
> >>>> qemu-system-ppc64 -nographic -nodefaults -m 256 \
> >>>> -hda /tmp/test.qcow2 -serial mon:stdio
> >>>>
> >>>> ... then switch to the monitor by pressing CTRL-a c and try to
> >>>> save a snapshot with "savevm test1" for example.
>
> Thomas
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* Re: [PATCH] drbd: Fix kernel_sendmsg() usage
From: Lars Ellenberg @ 2016-11-09 15:32 UTC (permalink / raw)
To: Jens Axboe
Cc: Richard Weinberger, wolfgang.glas, christoph.lechleitner,
philipp.reisner, stable, linux-kernel, viro, drbd-dev
In-Reply-To: <20161108165204.GC2834@kernel.dk>
On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote:
> > > This should go into 4.9,
> > > and into all stable branches since and including v4.0,
> > > which is the first to contain the exposing change.
> > >
> > > It is correct for all stable branches older than that as well
> > > (which contain the DRBD driver; which is 2.6.33 and up).
> > >
> > > It requires a small "conflict" resolution for v4.4 and earlier, with v4.5
> > > we dropped the comment block immediately preceding the kernel_sendmsg().
> > >
> > > Cc: stable@vger.kernel.org
> > > Cc: viro@zeniv.linux.org.uk
> > > Cc: christoph.lechleitner@iteg.at
> > > Cc: wolfgang.glas@iteg.at
> > > Reported-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
> > > Tested-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
> > > Signed-off-by: Richard Weinberger <richard@nod.at>
> > > Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
> >
> > Changing my patch is perfectly fine, but please clearly state it.
> > I.e. by adding something like that before your S-o-b.
> > [Lars: Massaged patch to match my personal taste...]
>
> Lars, are you sending a new one? If you do, add the stable tag as well.
So my "change" against his original patch was
- rv = kernel_sendmsg(sock, &msg, &iov, 1, size - sent);
+ rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len);
to make it "more obviously correct" from looking just at the one line
without even having to read the context. And a more verbose commit message.
If that requires yet additional noise, sure, so be it :)
Should I sent two patches, one that applies to 4.5 and later,
and one that applies to 2.6.33 ... 4.4, or are you or stable
willing to resolve the trivial "missing comment block" conflict yourself?
--
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support
DRBD� and LINBIT� are registered trademarks of LINBIT
^ permalink raw reply
* Re: [Drbd-dev] [PATCH] drbd: Fix kernel_sendmsg() usage
From: Lars Ellenberg @ 2016-11-09 15:32 UTC (permalink / raw)
To: Jens Axboe
Cc: wolfgang.glas, Richard Weinberger, christoph.lechleitner,
linux-kernel, stable, philipp.reisner, viro, drbd-dev
In-Reply-To: <20161108165204.GC2834@kernel.dk>
On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote:
> > > This should go into 4.9,
> > > and into all stable branches since and including v4.0,
> > > which is the first to contain the exposing change.
> > >
> > > It is correct for all stable branches older than that as well
> > > (which contain the DRBD driver; which is 2.6.33 and up).
> > >
> > > It requires a small "conflict" resolution for v4.4 and earlier, with v4.5
> > > we dropped the comment block immediately preceding the kernel_sendmsg().
> > >
> > > Cc: stable@vger.kernel.org
> > > Cc: viro@zeniv.linux.org.uk
> > > Cc: christoph.lechleitner@iteg.at
> > > Cc: wolfgang.glas@iteg.at
> > > Reported-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
> > > Tested-by: Christoph Lechleitner <christoph.lechleitner@iteg.at>
> > > Signed-off-by: Richard Weinberger <richard@nod.at>
> > > Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
> >
> > Changing my patch is perfectly fine, but please clearly state it.
> > I.e. by adding something like that before your S-o-b.
> > [Lars: Massaged patch to match my personal taste...]
>
> Lars, are you sending a new one? If you do, add the stable tag as well.
So my "change" against his original patch was
- rv = kernel_sendmsg(sock, &msg, &iov, 1, size - sent);
+ rv = kernel_sendmsg(sock, &msg, &iov, 1, iov.iov_len);
to make it "more obviously correct" from looking just at the one line
without even having to read the context. And a more verbose commit message.
If that requires yet additional noise, sure, so be it :)
Should I sent two patches, one that applies to 4.5 and later,
and one that applies to 2.6.33 ... 4.4, or are you or stable
willing to resolve the trivial "missing comment block" conflict yourself?
--
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support
DRBD® and LINBIT® are registered trademarks of LINBIT
^ permalink raw reply
* Re: [PATCH] t6026-merge-attr: don't fail if sleep exits early
From: Jeff King @ 2016-11-09 15:31 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <mvmzil8btzb.fsf@hawking.suse.de>
On Wed, Nov 09, 2016 at 03:36:40PM +0100, Andreas Schwab wrote:
> On Nov 09 2016, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > The reason why we do not ignore kill errors is that we want to make sure
> > that the script *actually ran*. Otherwise, the thing we need to test here
> > does not necessarily get tested.
>
> That can be tested by looking for the pid file.
I agree that makes the intent a lot more obvious. Having a necessary
condition of the test stuffed into a test_when_finished block seems
counter-intuitive.
-Peff
^ permalink raw reply
* Re: [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus
From: Boris Ostrovsky @ 2016-11-09 15:29 UTC (permalink / raw)
To: Andrew Cooper, xen-devel; +Cc: ian.jackson, wei.liu2, jbeulich, roger.pau
In-Reply-To: <47822815-6bc4-4a46-7d1f-d3ed67599a39@citrix.com>
On 11/09/2016 10:04 AM, Andrew Cooper wrote:
> On 09/11/16 14:39, Boris Ostrovsky wrote:
>> This domctl is called when a VCPU is hot-(un)plugged to a guest (via
>> 'xl vcpu-set'). While this currently is only intended to be needed by
>> PVH guests we will call this domctl for all (x86) guests for consistency.
>>
>> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>> Changes in v2:
>> * Added comment in arch_do_domctl() stating that the domctl is only required
>> for PVH guests
> I am not happy with this change until we understand why it is needed.
>
> Are we genuinely saying that there is no current enforcement in the
> PV-hotplug mechanism?
That's right. Don't call setup_cpu_watcher() in Linux and you will be
running with maxvcpus.
>
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 2a2fe04..b736d4c 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1430,6 +1430,23 @@ long arch_do_domctl(
>> }
>> break;
>>
>> + case XEN_DOMCTL_set_avail_vcpus:
>> + {
>> + unsigned int num = domctl->u.avail_vcpus.num;
>> +
>> + /*
>> + * This is currently only needed by PVH guests (but
>> + * any guest is free to make this call).
>> + */
>> + ret = -EINVAL;
>> + if ( num > d->max_vcpus )
>> + break;
>> +
>> + d->arch.avail_vcpus = num;
>> + ret = 0;
>> + break;
>> + }
> What do you actually mean by "avail_vcpus"? What happens if a vcpu
> higher than the new number is currently online and running? What
> happens to the already-existing vcpus-at-startup value?
It shouldn't happen: we set avail_vcpus at domain creation time to
vcpus-at-startup.
The name is not great. It would have been better to have it online_vcpus
but that usually means that VPF_down is set (which can happen, for
example, when the guest offlines a VCPU).
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [LTP] du01 with btrfs on systems with > 4k page size
From: Stanislav Kholmanskikh @ 2016-11-09 15:29 UTC (permalink / raw)
To: ltp
Hi!
On SPARC the default page size is 8k.
And du01 fails with btrfs at check3:
du01 3 TFAIL : 'du -a' failed
du01 4 TINFO : Looking for '[0-4][[:space:]]\.\/testdir\/testsymlink' in:
10240 ./testfile
8 ./testdir/testsymlink
8 ./testdir
10248 .
du01 4 TFAIL : 'du --all' failed
du01 5 TINFO : Looking for '[0-4][[:space:]]\.\/testdir\/testsymlink' in:
10240 ./testfile
8 ./testdir/testsymlink
8 ./testdir
10248 .
i.e. the testsymlink is 8k whereas at most 4k is expected by the test case.
In commit bdd09b1c6f2c8ad ("du01.sh: Fix failures on Btrfs on ppc64le")
a similar situation was fixed, but for check5 and check6. I'm curious
why check3 doesn't fail on ppc64. It seems it should fail with the
current code.
Could, please, anybody with access to a ppc64 box run this test case
with btrfs and/or provide the output from commands:
[root@skholman-m7 du]# cd /mnt
[root@skholman-m7 mnt]# mkdir basedir
[root@skholman-m7 mnt]# cd basedir/
[root@skholman-m7 basedir]# dd if=/dev/zero of=testfile bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00825522 s, 1.3 GB/s
[root@skholman-m7 basedir]# mkdir -p testdir
[root@skholman-m7 basedir]# ln -s ../testfile testdir/testsymlink
[root@skholman-m7 basedir]# du -a
10240 ./testfile
8 ./testdir/testsymlink
8 ./testdir
10248 .
[root@skholman-m7 basedir]#
?
Thanks.
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Dave Anderson @ 2016-11-09 15:28 UTC (permalink / raw)
To: Andrew Jones; +Cc: Dave Young, wency, qiaonuohan, lersek, qemu-devel, bhe
In-Reply-To: <20161109104059.bvw5h4k4v77pw2rl@kamzik.brq.redhat.com>
----- Original Message -----
> On Wed, Nov 09, 2016 at 11:01:46AM +0800, Dave Young wrote:
> > Hi,
> >
> > Latest linux kernel enabled kaslr to randomiz phys/virt memory
> > addresses, we had some effort to support kexec/kdump so that crash
> > utility can still works in case crashed kernel has kaslr enabled.
> >
> > But according to Dave Anderson virsh dump does not work, quoted messages
> > from Dave below:
> >
> > """
> > with virsh dump, there's no way of even knowing that KASLR
> > has randomized the kernel __START_KERNEL_map region, because there is no
> > virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> > vmcoreinfo data to compare against the vmlinux file symbol value.
> > Unless virsh dump can export some basic virtual memory data, which
> > they say it can't, I don't see how KASLR can ever be supported.
> > """
> >
> > I assume virsh dump is using qemu guest memory dump facility so it
> > should be first addressed in qemu. Thus post this query to qemu devel
> > list. If this is not correct please let me know.
> >
> > Could you qemu dump people make it work? Or we can not support virt dump
> > as long as KASLR being enabled. Latest Fedora kernel has enabled it in
> > x86_64.
> >
>
> When the -kernel command line option is used, then it may be possible
> to extract some information that could be used to supplement the memory
> dump that dump-guest-memory provides. However, that would be a specific
> use. In general, QEMU knows nothing about the guest kernel. It doesn't
> know where it is in the disk image, and it doesn't even know if it's
> Linux.
>
> Is there anything a guest userspace application could probe from e.g.
> /proc that would work? If so, then the guest agent could gain a new
> feature providing that.
>
> Thanks,
> drew
I'm not sure whether this "guest userspace agent" is still in play here,
but if there were such a thing, it could theoretically do the same
thing that crash currently does when running on a live system.
Two basic necessities are are needed, whether running live or against
a dumpfile:
(1) the CONFIG_RANDOMIZE_BASE relocation value that modifies the
kernel virtual address range compiled into the vmlinux file, which
starts at the hardwired __START_KERNEL_map address.
(2) the contents of the kernel's "phys_base" symbol.
Both of those are available or calculatable from the contents of
a kdump header. However, on a live system, it's done like this:
- /proc/kallsyms is queried for the symbol value of "_text", which would
be relocated if KASLR is in play. That value is compared against the
"_text" symbol value compiled into the vmlinux file to determine the
relocation value generated by CONFIG_RANDOMIZE_BASE.
Given that relocation value, and before any kernel memory is accessed,
crash goes in a backdoor into its embedded gdb module, and modifies
the data structures of all kernel symbols, applying the relocation
value.
Once that's done, in order to read kernel symbols from the
statically-mapped kernel region based at __START_KERNEL_map, it
translates a (possibly relocated) kernel virtual address into a
physical address like this:
physical-address = virtual-address - __START_KERNEL_map + phys_base
But it's a chicken-and-egg deal, because the contents of the "phys_base"
symbol are needed to calculate the physical address, but it can't
read the "phys_base" symbol contents without first knowing its contents.
So on a live system, the "phys_base" is calculated by reading
the "Kernel Code:" value from /proc/iomem, and then doing this:
phys_base = [Kernel Code: value] - ["_text" symbol value] - __START_KERNEL_map
So theoretically, the guest agent could read /proc/iomem and /proc/kallsyms
for the information required. (I think...)
Dave
^ permalink raw reply
* Re: [Qemu-devel] [PATCH for-2.8] migration: Fix return code of ram_save_iterate()
From: Thomas Huth @ 2016-11-09 15:28 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: Amit Shah, Juan Quintela, qemu-devel, David Gibson
In-Reply-To: <20161109151351.GC7738@work-vm>
On 09.11.2016 16:13, Dr. David Alan Gilbert wrote:
> * Thomas Huth (thuth@redhat.com) wrote:
>> On 09.11.2016 08:18, Amit Shah wrote:
>>> On (Fri) 04 Nov 2016 [14:10:17], Thomas Huth wrote:
>>>> qemu_savevm_state_iterate() expects the iterators to return 1
>>>> when they are done, and 0 if there is still something left to do.
>>>> However, ram_save_iterate() does not obey this rule and returns
>>>> the number of saved pages instead. This causes a fatal hang with
>>>> ppc64 guests when you run QEMU like this (also works with TCG):
>>>
>>> "works with" -- does that mean reproduces with?
>>
>> Yes, that's what I've meant: You can reproduce it with TCG (e.g. running
>> on a x86 system), too, there's no need for a real POWER machine with KVM
>> here.
>
> How did you trigger it on x86?
As described below - qemu-img + qemu-system-ppc64 + savevm is enough to
trigger it on a x86 host.
>
>>>> qemu-img create -f qcow2 /tmp/test.qcow2 1M
>>>> qemu-system-ppc64 -nographic -nodefaults -m 256 \
>>>> -hda /tmp/test.qcow2 -serial mon:stdio
>>>>
>>>> ... then switch to the monitor by pressing CTRL-a c and try to
>>>> save a snapshot with "savevm test1" for example.
Thomas
^ permalink raw reply
* Re: Status for bug 71211? [random(4): clarify utility and volume]
From: Michael Kerrisk (man-pages) @ 2016-11-09 15:27 UTC (permalink / raw)
To: Laurent Georget, Carl Winbäck, nmav-H+wXaHxf7aLQT0dZR+AlfA
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, Stephan Mueller, George Spelvin,
Theodore T'so, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
In-Reply-To: <55B65DAC.6010906-AyimVQWTEHzsq35pWSNszA@public.gmane.org>
Nikos,
This was an earlier mail from Laurent Georget. I bring
you into this thread in case there's any of Laurent's comments
that may be helpful as inspiration for your patch.
See also https://bugzilla.kernel.org/show_bug.cgi?id=71211
Cheers,
Michael
On 07/27/2015 06:34 PM, Laurent Georget wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hello,
>
> the text of this man page has been the subject of endless controversies
> for ages. CSPRNGs are confusing and the page unfortunately adds a
> little to the confusion. The newer getrandom(2) page is better, and I
> (personally, this doesn't engage Michael nor any other author) think
> that the random(4) page should be rewritten in the same spirit.
> (getrandom is a system call used to get a random number, by default,
> it's more or less equivalent than reading from /dev/urandom if you call
> it without flags and for less than 256 bytes).
>
> Compare this in random(4)
>
>> The kernel random-number generator is designed to produce a small
>> amount of high-quality seed material to seed a cryptographic pseudo-
>> random number generator (CPRNG). It is designed for security, not
>> speed, and is poorly suited to generating large amounts of random
>> data. Users should be very economical in the amount of seed material
>> that they read from /dev/urandom (and /dev/random); unnecessarily
>> reading large quantities of data from this device will have a
>> negative impact on other users of the device.
> with this in getrandom(2)
>
>> *getrandom*() relies on entropy gathered from device drivers and other
>> sources of environmental noise. Unnecessarily reading large
>> quantities of data will have a negative impact on other users of the
>> //dev/random/ and //dev/urandom/ devices. Therefore, *getrandom*() should
>> not be used for Monte Carlo simulations or other programs/algorithms
>> which are doing probabilistic sampling.
> This says exactly the same thing, but getrandom(2) is less misleading.
> First note that the man page for random says that /dev/urandom is
> "poorly suited to generating large amounts of random data", not
> "poorly suited to generating large amounts of *cryptographic* random data".
> Basically, you can use /dev/urandom for all cryptographic purposes,
> because you never need so many bits at once when doing cryptography.
> Even generating several 16-bytes (128-bits) UIDs per minute if you need
> them to be cryptographically secure (you may want to think about this
> requirement, is it strict?) is not that much. A Monte-Carlo simulation
> requires, say (I don't know exactly let's make a rough guess) around
> several MB of random numbers per minute. That's 4 or 5 orders of
> magnitude higher than your UIDs use case. This would be a wrong
> usage of /dev/urandom for two reasons:
> - - it would be awfully slow
> - - you don't need cryptographically secure random numbers, so there's
> no need to deplete the entropy pool.
> Next, compare this in random(4):
>
>> If you are unsure about whether you should use /dev/random or
>> /dev/urandom, then probably you want to use the latter. As a general
>> rule, /dev/urandom should be used for everything except long-lived
>> GPG/SSL/SSH keys.
> with this in getrandom(2):
>
>> Unless you are doing long-term key generation (and perhaps not even
>> then), you probably shouldn't be using GRND_RANDOM. The cryptographic
>> algorithms used for /dev/urandom are quite conservative, and so should
>> be sufficient for all purposes. The disadvantage of GRND_RANDOM is
>> that it can block. Furthermore, dealing with the partially fulfilled
>> getrandom() requests that can occur when using GRND_RANDOM increases
>> code complexity.
> Again, the two man pages say the same. getrandom(2) is more nuanced,
> though.
>
> To answer your question about how much you can ask /dev/urandom for :
>
> in random(4) :
>
>> if any program reads more than 256 bits (32 bytes) from the kernel random
>> pool per invocation, or per reasonable reseed interval (not less than
>> one minute), that should be taken as a sign that its cryptography is
>> not skillfully implemented.
> In getrandom(2):
>
>> Calling getrandom() to read /dev/urandom for small values (<= 256 bytes)
>> of buflen is the preferred mode of usage.
> Furthermore, it's impossible to read more than 32MB from /dev/urandom
> per invocation.
>
> So, actually, the random(4) page is very conservative about the reading
> limit.
>
> My final conclusion: as long as you use /dev/urandom for cryptographic
> purposes only, you should be ok, because you will never need *a lot* of
> random data anyway in any sensible program. For non-cryptographic usage,
> seed a user-space PRNG with a few bytes from /dev/urandom and you will
> be good.
>
> Laurent
>
>
>
> Le 26/07/2015 22:20, Carl Winbäck a écrit :
>> Hello Michael & Co,
>>
>> I would like to bring your attention to bug report 71211, ”random(4):
>> clarify utility and volume”.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=71211
>>
>> This report was filed over a year ago but still hasn’t received any response.
>>
>> Michael, do you have the time to take a look?
>>
>> Perhaps you, or someone else on the linux-man list, are familiar with
>> CSPRNGs and have some ideas on how to reword this man page?
>>
>> Unfortunately I’m not at all an expert in this area, so I’m afraid I
>> don’t have any specific suggestions regarding how to change this man
>> page. But I still think it would be helpful to the Linux community if
>> it could be improved, and as a result, hopefully cause less confusion
>> regarding getting random numbers on Linux.
>>
>>
>> Looking forward to hear your thoughts on this.
>>
>> Best regards,
>> Carl Winbäck
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-man" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iF4EAREIAAYFAlW2XawACgkQRTidSplJch4jJQD/d4LOrShlXmQx5RClVCdj7sKL
> 6n7SQhlCIjfqvi86JDcA/28cCtYZ8HKL1RgWkgEjGmWoIH6ZA+AKJjgnmugk1wFj
> =ff9U
> -----END PGP SIGNATURE-----
>
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [Buildroot] ninja/python-meson packages
From: Cédric Marie @ 2016-11-09 15:26 UTC (permalink / raw)
To: buildroot
Hi,
Regarding python-meson package that was proposed here:
http://lists.busybox.net/pipermail/buildroot/2016-June/163437.html
>> However, I could provide a real package infrastructure named
>> "meson-package",
>> but as stated in the discussion about adding support for Cargo (the
>> Rust
>> package manager), to provide such infrastructure, at least one package
>> using
>> it should also be provided (it is sensible to have a working example
>> of
>> the infrastructure).
> I would not say one, but at least 4-5 packages, with a pretty good
> confidence that more packages would be added later on.
Gstreamer has added Meson as an alternative build system (to Autotools)
since August 2016:
https://cgit.freedesktop.org/gstreamer/gstreamer/commit/meson.build?id=b2f9808722a0254acba17ef98a612a2792184e12
And I suppose that other projects are likely to switch... The decrease
of build time is really interesting compared to Autotools, CMake, and
even CMake with ninja backend.
By the way, is there any chance to give CMake package the possibility to
use ninja backend? (which will also decrease build time of CMake
packages)
I have local modifications of my buildroot tree that achieve that, but
I'm not sure about the right way to propose it. I have added an option
(BR2_PACKAGE_CMAKE_NINJA) but it appears in target packages >
Development tools, while it is not intended for the target. Would it be
a better idea to create a specific package infra (pkg-cmake-ninja.mk)?
Or maybe it is just not useful... I don't know whether the user really
needs to choose between two different backends, while the result is
supposed to be the same (only the build time will differ).
NB: Comparison of build time can be found here:
https://github.com/mesonbuild/meson/wiki/Simple%20comparison
--
C?dric
^ permalink raw reply
* Re: [PATCH] Update the random(4) documentation towards a more accurate view on /dev/urandom
From: Michael Kerrisk (man-pages) @ 2016-11-09 15:26 UTC (permalink / raw)
To: George Spelvin, nmav-H+wXaHxf7aLQT0dZR+AlfA
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ,
tytso-3s7WtUTddSA, Stephan Mueller, Carl Winbäck,
Laurent Georget
In-Reply-To: <20160426165847.5804.qmail-HzZAx2gCgqrSUeElwK9/Pw@public.gmane.org>
Hello Nikos,
This was the mail from George that I just referred to in my
other mail. Is there anything that needs to be covered here?
Some specific comments below.
On 04/26/2016 06:58 PM, George Spelvin wrote:
> Nikos Mavrogiannopoulos wrote:
>> On Mon, 2016-04-25 at 11:46 -0400, George Spelvin wrote:
>>> Removing the examples of high quality randomness I'm less fond of;
>>> the whole idea is to inform people who don't quite understand what
>>> the general terms mean. Good enough for one-time pads is a design
>>> goal of /dev/random.
>
>> If that's about documenting a design goal I'd prefer to move it out of
>> the main text for 2 reasons. (a) There is no practical crypto system
>> using one time pads, thus mentioning it in the main body only creates
>> confusion (b), one time pad is such a theoretical construction that any
>> real algorithm wouldn't implement it.
>
> The original (removed by your patch) line was:
>
> -high quality randomness such as one-time pad or key generation.
>
> It's not the words "one-time pad" I'm attached to, but the specific
> examples of when "high-quality randomness" is required. A big point is
> to teach people *how* to use it, and without those examples, when would
> anyone think "my application wants low-quality randomness"?
>
> You're right that a one-time pad is impractical, but it's still
> a common and familiar pedagogical example, and more importantly
> something that a person wondering which to use can see that their
> application is NOT.
>
> Your proposed patch *also* deleted the other usage example at the end:
>
> -should be used for everything except long-lived GPG/SSL/SSH keys.
>
> which really reduces the value of the man page as a guide to people
> who aren't crypto experts.
Nikos, what are your thoughts on the above comments?
>>> The bit about early boot is actually not as much of an issue as you
>>> think.
>>>
>>> Even /dev/urandom will stall early on boot until a minimum initial seed
>>> (128 bits at present) has been acumulated. (grep for "urandom_init_wait")
>
>> No it will not. We notice often the keys for sshd being generated
>> *before* the kernel logs that the random pool has been
>> initialized.
>
> H'm... observation definitely trumps theoretical predictions based on
> reading the code.
>
> Is that a documentation problem or a code bug, or something I'm not
> understanding properly? If you look for that symbol in the source
> it definitely looks like it's supposed to wait for initial seeding.
> And ssh-keygen uses /dev/urandom.
>
> The getrandom(2) man page also documents the block-on-startup behavior.
>
> The driver wakes up the sleeping readers *before* printing
> the message. Is it possible that syslog is just losing the race?
Anything from the above that is relevant to add to your patch?
>>> How about something more like (draft, not final edit):
>>>
>>> A read from the \fI/dev/urandom\fP device will not block
>>> waiting for more entropy.
>>> +If the estimated fresh entropy is not sufficient, a
>>> \fI/dev/urandom\fP
>>> +will produce output anyway, relying on the cryptographic primitives
>>> in
>>> +the driver's pseudo-random number generator to ensure that the
>>> output,
>>> +although correlated with previous output in an information theoretic
>>> +sense (it exceeds the unicity distance), is secure for all practical
>>> +purposes.
>
>> What is the purpose of this text? To whom does it target?
>
> To replace the text
>
> -If there is not sufficient entropy, a pseudorandom number generator is used
> -to create the requested bytes.
>
> or
>
> +If the estimated fresh entropy is not sufficient, a pseudorandom number generator is
> +used to create the requested bytes.
>
> with something that doesn't imply a mode switch.
>
> I labelled it "draft" because I wasn't really thrilled with the wording,
> myself, but I thought it gave the general idea and wasn't worth massaging
> into editorial perfection since it was due to get torn apart anyway.
>
> Can you think of better wording? I'm all for keeping it simple, but
> not at the expense of seriously misleading people.
Comments?
>> I wouldn't like to get into such details about the device in the manpage,
>> but if you would like a section studying the theoretical properties of
>> /dev/urandom I'd again suggest to keep it separate and elaborate. What
>> is on the text above is certainly not complete analysis and is certainly
>> not targetting administrators and developers who would like to understand
>> what this device does.
>
> A reorganization might indeed be a good way forward; I was examining
> your changes without stepping back and considering the whole forest.
>
> Shall I take a stab at it?
Comments? Nikos? George?
>>> I don't like the bit about "use /dev/random or getrandom(2)"; while
>>> getrandom(2) should be mentioned in "see also", the equivalent is
>>> "getrandom(..., GRND_RANDOM)". It's the flag, no the syscall.
>
>> It is the syscall. According the description in getrandom(2):
>> "If the pool has not yet been initialized, then the call blocks,
>> unless GRND_RANDOM is specified in flags."
>
> 1. You have a buggy man page. The corrected one says "If the pool has
> not yet been initialized, then the call blocks, unless GRND_NONBLOCK
> is specified in flags."
>
> 2. I stand by what I wrote above. Without the GRND_RANDOM flag,
> getrandom() access the nonblocking pool (/dev/urandom).
>
>>> I strongly dislike the deletion of the "as a general rule" advice.
>>> Specific recommendations are very valuable.
>
>> This advice despite being present for so long, is widely ignored as
>> /dev/urandom is used unconditionally by all software generating keys
>> (SSH/SSL), gnupg being the exception.
>
> No, it's not being ignored. The advice isn't "use /dev/random for
> SSH keys", but "*don't* use /dev/random for anything *except* SSH
> keys". The "(and maybe not even then)" part is implicit, but much
> less of a concern.
>
> The audience is not the authors of ssh, libssl, or gnupg; they know
> what they're doing. The audience is everyone *else*, and I think
> specific examples really help there.
Comments?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Applied "ASoC: Intel: Skylake: remove pci device enabling calls on suspend" to the asoc tree
From: Mark Brown @ 2016-11-09 15:25 UTC (permalink / raw)
To: Jayachandran B
Cc: Vinod Koul, liam.r.girdwood, alsa-devel, broonie, patches.audio
In-Reply-To: <1474868137-29712-11-git-send-email-vinod.koul@intel.com>
The patch
ASoC: Intel: Skylake: remove pci device enabling calls on suspend
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 68d03a3aa2747e1a33231950d2c8369f1cef4244 Mon Sep 17 00:00:00 2001
From: Jayachandran B <jayachandran.b@intel.com>
Date: Thu, 3 Nov 2016 17:07:22 +0530
Subject: [PATCH] ASoC: Intel: Skylake: remove pci device enabling calls on
suspend
We were invoking pci_disable_device() while going to suspend-to-idle and
pci_enable_device() while coming back to active state.
Turns out that we do not need these calls as we only need system to be
wake capable when in suspend-to-idle state. The wake capability is
already done by enable_irq_wake() calls, so remove these unwanted calls
in driver.
Signed-off-by: Jayachandran B <jayachandran.b@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/intel/skylake/skl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index b9209af89915..ed59783e9846 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -290,7 +290,6 @@ static int skl_suspend(struct device *dev)
enable_irq_wake(bus->irq);
pci_save_state(pci);
- pci_disable_device(pci);
} else {
ret = _skl_suspend(ebus);
if (ret < 0)
@@ -333,7 +332,6 @@ static int skl_resume(struct device *dev)
*/
if (skl->supend_active) {
pci_restore_state(pci);
- ret = pci_enable_device(pci);
snd_hdac_ext_bus_link_power_up_all(ebus);
disable_irq_wake(bus->irq);
/*
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: Intel: Skylake: Flush pending D0i3 request on suspend" to the asoc tree
From: Mark Brown @ 2016-11-09 15:25 UTC (permalink / raw)
To: Jayachandran B
Cc: Vinod Koul, liam.r.girdwood, alsa-devel, broonie, patches.audio
In-Reply-To: <1474868137-29712-10-git-send-email-vinod.koul@intel.com>
The patch
ASoC: Intel: Skylake: Flush pending D0i3 request on suspend
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 8b4a133c6145a34618c770117b65b33f1aa993aa Mon Sep 17 00:00:00 2001
From: Jayachandran B <jayachandran.b@intel.com>
Date: Thu, 3 Nov 2016 17:07:21 +0530
Subject: [PATCH] ASoC: Intel: Skylake: Flush pending D0i3 request on suspend
While going to suspend, if we have any pending D0i3 work scheduled,
flush that and force the DSP to goto D0i3 mode before going to suspend.
Signed-off-by: Jayachandran B <jayachandran.b@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/intel/skylake/skl-messages.c | 27 +++++++++++++++++++++++++++
sound/soc/intel/skylake/skl.c | 10 ++++++++++
sound/soc/intel/skylake/skl.h | 1 +
3 files changed, 38 insertions(+)
diff --git a/sound/soc/intel/skylake/skl-messages.c b/sound/soc/intel/skylake/skl-messages.c
index 87fc647fa04c..4ae021aabc3a 100644
--- a/sound/soc/intel/skylake/skl-messages.c
+++ b/sound/soc/intel/skylake/skl-messages.c
@@ -294,6 +294,33 @@ int skl_free_dsp(struct skl *skl)
return 0;
}
+/*
+ * In the case of "suspend_active" i.e, the Audio IP being active
+ * during system suspend, immediately excecute any pending D0i3 work
+ * before suspending. This is needed for the IP to work in low power
+ * mode during system suspend. In the case of normal suspend, cancel
+ * any pending D0i3 work.
+ */
+int skl_suspend_late_dsp(struct skl *skl)
+{
+ struct skl_sst *ctx = skl->skl_sst;
+ struct delayed_work *dwork;
+
+ if (!ctx)
+ return 0;
+
+ dwork = &ctx->d0i3.work;
+
+ if (dwork->work.func) {
+ if (skl->supend_active)
+ flush_delayed_work(dwork);
+ else
+ cancel_delayed_work_sync(dwork);
+ }
+
+ return 0;
+}
+
int skl_suspend_dsp(struct skl *skl)
{
struct skl_sst *ctx = skl->skl_sst;
diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c
index ed59783e9846..61a484888cfa 100644
--- a/sound/soc/intel/skylake/skl.c
+++ b/sound/soc/intel/skylake/skl.c
@@ -228,6 +228,15 @@ static int skl_acquire_irq(struct hdac_ext_bus *ebus, int do_disconnect)
return 0;
}
+static int skl_suspend_late(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+ struct hdac_ext_bus *ebus = pci_get_drvdata(pci);
+ struct skl *skl = ebus_to_skl(ebus);
+
+ return skl_suspend_late_dsp(skl);
+}
+
#ifdef CONFIG_PM
static int _skl_suspend(struct hdac_ext_bus *ebus)
{
@@ -390,6 +399,7 @@ static int skl_runtime_resume(struct device *dev)
static const struct dev_pm_ops skl_pm = {
SET_SYSTEM_SLEEP_PM_OPS(skl_suspend, skl_resume)
SET_RUNTIME_PM_OPS(skl_runtime_suspend, skl_runtime_resume, NULL)
+ .suspend_late = skl_suspend_late,
};
/*
diff --git a/sound/soc/intel/skylake/skl.h b/sound/soc/intel/skylake/skl.h
index 88ba54ba5f72..4986e3929dd3 100644
--- a/sound/soc/intel/skylake/skl.h
+++ b/sound/soc/intel/skylake/skl.h
@@ -124,6 +124,7 @@ int skl_get_dmic_geo(struct skl *skl);
int skl_nhlt_update_topology_bin(struct skl *skl);
int skl_init_dsp(struct skl *skl);
int skl_free_dsp(struct skl *skl);
+int skl_suspend_late_dsp(struct skl *skl);
int skl_suspend_dsp(struct skl *skl);
int skl_resume_dsp(struct skl *skl);
void skl_cleanup_resources(struct skl *skl);
--
2.10.2
^ permalink raw reply related
* Re: [RFC v3 1/6] Track the active utilisation
From: luca abeni @ 2016-11-09 15:25 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, Peter Zijlstra, Ingo Molnar, Claudio Scordino,
Steven Rostedt
In-Reply-To: <20161108200229.GA24076@ARMvm>
On Tue, 8 Nov 2016 20:02:29 +0000
Juri Lelli <juri.lelli@arm.com> wrote:
[...]
> > > So, it actually matters for next patch,
> > > not here. But, maybe we want to do things clean from start?
> > You mean, because patch 2/6 adds
> > + if (hrtimer_active(&p->dl.inactive_timer)) {
> > + raw_spin_lock_irq(&task_rq(p)->lock);
> > + sub_running_bw(&p->dl, dl_rq_of_se(&p->dl));
> > + raw_spin_unlock_irq(&task_rq(p)->lock);
> > + }
> > in task_dead_dl()? I suspect this hunk is actually unneeded (worse, it
> > is wrong :). I am trying to remember why it is there, but I cannot find
> > any reason... In the next days, I'll run some tests to check if that
> > hunk is actually needed. If yes, then I'll modify patch 1/6 as you
> > suggest; if it is not needed, I'll remove it from patch 2/6 and I'll
> > not do this change to patch 1/6... Is this ok?
> >
>
> I guess yes, if we don't need to differentiate.
Ok; so, I ran some tests (and I found some old notes of mine). The
modifications to task_dead_dl() mentioned above are not actually needed;
I added them as a preparation for a change needed by patch 3... But I
now think this was an error; I am reworking this part of the code
(removing changes from task_dead_dl() and adding a "p->state == TASK_DEAD"
check in the inactive timer handler).
I'll post an update for patches 2 and 3 in few days, after I finish
some more tests.
Luca
> Maybe just add a comment as I am saying above?
>
> Thanks,
>
> - Juri
^ permalink raw reply
* RE: Shouldn't VFIO virtualize the ATS capability?
From: Ilya Lesokhin @ 2016-11-09 15:25 UTC (permalink / raw)
To: Alex Williamson
Cc: linux-pci@vger.kernel.org, kvm@vger.kernel.org,
bhelgaas@google.com, Adi Menachem
In-Reply-To: <20161109080746.24dd79dd@t450s.home>
> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Wednesday, November 09, 2016 5:08 PM
> To: Ilya Lesokhin <ilyal@mellanox.com>
> Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org; bhelgaas@google.com;
> Adi Menachem <adim@mellanox.com>
> Subject: Re: Shouldn't VFIO virtualize the ATS capability?
>=20
> On Wed, 9 Nov 2016 14:49:02 +0000
> Ilya Lesokhin <ilyal@mellanox.com> wrote:
>=20
> > I would virtualize the "ATS Control Register".
>=20
> And do what?
I think it should be read only.
>=20
> > Regarding poor behavior, I couldn't really find what happens when ATS i=
s
> misconfigured, but I would assume it can cause problems.
> > The scenarios I'm concerned about are:
> > 1. The guest enables translation caching, while the hypervisor thinks
> there are disabled -> Hypervisor won't issue invalidations.
>=20
> Aren't invalidations issued by the iommu, why does the hypervisor need to
> participate? How would a software entity induce an invalidation?
That's what one might expect from a sane design, but
http://lxr.free-electrons.com/source/drivers/iommu/intel-iommu.c?v=3D4.8#L1=
549
seems to imply otherwise :(
>=20
> > 2. Smallest Translation Unit misconfiguration. Not sure if it will cau=
se
> invalid access or only poor caching behavior.
> >
> > Thanks,
> > Ilya
> >
> > > -----Original Message-----
> > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > Sent: Sunday, November 06, 2016 7:09 PM
> > > To: Ilya Lesokhin <ilyal@mellanox.com>
> > > Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org;
> > > bhelgaas@google.com
> > > Subject: Re: Shouldn't VFIO virtualize the ATS capability?
> > >
> > > On Sun, 6 Nov 2016 11:13:09 +0000
> > > Ilya Lesokhin <ilyal@mellanox.com> wrote:
> > >
> > > > Hi
> > > > I've noticed that VFIO doesn't virtualize the ATS capability.
> > > > It seems to me that translation caching and Smallest Translation
> > > > Unit is
> > > something you would want to control on the host. Am I wrong?
> > >
> > > What about those fields would we virtualize? Why does the host need
> > > to be an intermediary? Can the user induce poor behavior with
> > > direct access to them? Thanks,
> > >
> > > Alex
^ permalink raw reply
* RE: Shouldn't VFIO virtualize the ATS capability?
From: Ilya Lesokhin @ 2016-11-09 15:25 UTC (permalink / raw)
To: Alex Williamson
Cc: linux-pci@vger.kernel.org, kvm@vger.kernel.org,
bhelgaas@google.com, Adi Menachem
In-Reply-To: <20161109080746.24dd79dd@t450s.home>
> -----Original Message-----
> From: Alex Williamson [mailto:alex.williamson@redhat.com]
> Sent: Wednesday, November 09, 2016 5:08 PM
> To: Ilya Lesokhin <ilyal@mellanox.com>
> Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org; bhelgaas@google.com;
> Adi Menachem <adim@mellanox.com>
> Subject: Re: Shouldn't VFIO virtualize the ATS capability?
>
> On Wed, 9 Nov 2016 14:49:02 +0000
> Ilya Lesokhin <ilyal@mellanox.com> wrote:
>
> > I would virtualize the "ATS Control Register".
>
> And do what?
I think it should be read only.
>
> > Regarding poor behavior, I couldn't really find what happens when ATS is
> misconfigured, but I would assume it can cause problems.
> > The scenarios I'm concerned about are:
> > 1. The guest enables translation caching, while the hypervisor thinks
> there are disabled -> Hypervisor won't issue invalidations.
>
> Aren't invalidations issued by the iommu, why does the hypervisor need to
> participate? How would a software entity induce an invalidation?
That's what one might expect from a sane design, but
http://lxr.free-electrons.com/source/drivers/iommu/intel-iommu.c?v=4.8#L1549
seems to imply otherwise :(
>
> > 2. Smallest Translation Unit misconfiguration. Not sure if it will cause
> invalid access or only poor caching behavior.
> >
> > Thanks,
> > Ilya
> >
> > > -----Original Message-----
> > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > Sent: Sunday, November 06, 2016 7:09 PM
> > > To: Ilya Lesokhin <ilyal@mellanox.com>
> > > Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org;
> > > bhelgaas@google.com
> > > Subject: Re: Shouldn't VFIO virtualize the ATS capability?
> > >
> > > On Sun, 6 Nov 2016 11:13:09 +0000
> > > Ilya Lesokhin <ilyal@mellanox.com> wrote:
> > >
> > > > Hi
> > > > I've noticed that VFIO doesn't virtualize the ATS capability.
> > > > It seems to me that translation caching and Smallest Translation
> > > > Unit is
> > > something you would want to control on the host. Am I wrong?
> > >
> > > What about those fields would we virtualize? Why does the host need
> > > to be an intermediary? Can the user induce poor behavior with
> > > direct access to them? Thanks,
> > >
> > > Alex
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v13 1/2] virtio-crypto: Add virtio crypto device specification
From: Cornelia Huck @ 2016-11-09 15:24 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org, Huangweidong (C), mst@redhat.com,
john.griffin@intel.com, Shiqing Fan, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, Hanweidong (Randy), agraf@suse.de,
nmorey@kalray.eu, vincent.jardin@6wind.com, Ola.Liljedahl@arm.com,
Luonengjun, xin.zeng@intel.com, Huangpeng (Peter),
liang.j.ma@intel.com, stefanha@redhat.com, Jani Kokkonen,
brian.a.keating@intel.com, Claudio Fontana, mike.caraman@nxp.com,
Wubin (H)
In-Reply-To: <33183CC9F5247A488A2544077AF19020B0421668@SZXEMA503-MBS.china.huawei.com>
On Wed, 9 Nov 2016 01:11:20 +0000
"Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:
> Nope, Actually I kept those description here is because I wanted to represent each packet
> Intuitionally, otherwise I don't know how to explain them only occupy one entry in desc table
> by indirect table method. So I changed the code completely as Stefan's suggestion and
> revised the spec a little.
I think you need to revise the spec a bit more :) IIUC, you should
simply state that you use the indirect table method and not mention any
guest physical addresses.
> This just is a representative of the realization so that the people can easily understand what
> the virtio crypto request's components. It isn't completely same with the code.
> For virtio-scsi device, the struct virtio_scsi_req_cmd also used this way IIUR.
It seemes to have caused at least some confusion - perhaps you
simplyfied too much?
^ permalink raw reply
* We could not deliver your parcel, #00535004
From: FedEx International Economy @ 2016-11-09 15:24 UTC (permalink / raw)
To: linux-nvdimm
Dear Customer,
Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.
Warm regards,
Albert Gibbons,
Sr. Operation Manager.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH] Update the random(4) documentation towards a more accurate view on /dev/urandom
From: Michael Kerrisk (man-pages) @ 2016-11-09 15:23 UTC (permalink / raw)
To: Nikos Mavrogiannopoulos
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, tytso-3s7WtUTddSA,
George Spelvin, Stephan Mueller, Carl Winbäck,
Laurent Georget, mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ
In-Reply-To: <1476952646.2522.10.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[I'm looping a few people into this mail who previously commented
on this page. Nikos, I will also thread you into an earlier mail
by Laurent Georget.]
Hello Nikos,
Sorry that I have been so slow to follow up on this.
Thanks for your persistence. I have some comments
that probably require some tweaks to your patch.
I also have some questions about a couple of other
earlier discussions.
On 10/20/2016 10:37 AM, Nikos Mavrogiannopoulos wrote:
> On Mon, 2016-08-01 at 13:48 +0200, Nikos Mavrogiannopoulos wrote:
>> > This is an updated patch reflecting the recent discussion in linux-
>> > crypto:
>> > http://www.mail-archive.com/linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg20400.html
> Hi,
> I'm resending the patch with few typo fixes, and adding Ted in CC for
> review. Ted would you like to review this patch for the random(4)
> manpage?
Some comments below.
But one question first. You didn't further reply to George
Spelvin's comments on 26 April. Did you consider those comments
irrelevant or already addressed or something else?
By the way, inline patches are rather easier for me to deal with.
> 0001-Update-the-random-4-documentation-towards-a-more-acc.patch
>
>
> From 7952cf6bbabf36a4be50a3ba953278077f7b5157 Mon Sep 17 00:00:00 2001
> From: Nikos Mavrogiannopoulos <nmav-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date: Thu, 7 Apr 2016 09:08:14 +0200
> Subject: [PATCH] Update the random(4) documentation towards a more accurate
> view on /dev/urandom
>
> This documents the "property" of /dev/urandom of being able to serve numbers
> prior to pool being initialized, and removes any suggested usages of /dev/random
> which are disputable (i.e., one-time pad).
> Document the fact /dev/random is a legacy interface and only suitable for
> applications which can afford indeterminate delays since very few applications
> can do so.
>
> Signed-off-by: Nikos Mavrogiannopoulos <nmav-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> man4/random.4 | 51 ++++++++++++++++++++++++++-------------------------
> 1 file changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/man4/random.4 b/man4/random.4
> index b67c46f..c7afaf4 100644
> --- a/man4/random.4
> +++ b/man4/random.4
> @@ -13,8 +13,9 @@
> .\" 2004-04-08, AEB, Improved description of read from /dev/urandom
> .\" 2008-06-20, George Spelvin <linux-gpGsJRJZ3PBBDgjK7y7TUQ@public.gmane.org>,
> .\" Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>
> -.\" Add a Usage subsection that recommends most users to use
> -.\" /dev/urandom, and emphasizes parsimonious usage of /dev/random.
> +.\" 2016-10-20, Nikos Mavrogiannopoulos <nmav-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> +.\" Mention that /dev/random is a legacy interface and removed suggested
> +.\" uses of /dev/random.
No need to update this in-page changelog. We use git these days.
> .\"
> .TH RANDOM 4 2016-10-08 "Linux" "Linux Programmer's Manual"
> .SH NAME
> @@ -37,11 +38,22 @@ The generator also keeps an estimate of the
> number of bits of noise in the entropy pool.
> From this entropy pool random numbers are created.
> .LP
> -When read, the \fI/dev/random\fP device will return random bytes
> -only within the estimated number of bits of noise in the entropy
> -pool.
> -\fI/dev/random\fP should be suitable for uses that need very
> -high quality randomness such as one-time pad or key generation.
> +When read, the \fI/dev/urandom\fP device return random bytes using a pseudorandom
> +number generator seeded from the entropy pool. That operation is
> +non-blocking. When used during early boot time, this device may return
> +data prior to the entropy pool being initialized.
> +If this is of concern in your application, use
> +.BR getrandom(2)
> +or \fI/dev/random\fP instead.
> +
> +.LP
> +The \fI/dev/random\fP device is a legacy interface which dates back to
> +a time where the cryptographic primitives used in the implementation
s%in the implementation%in the implementation of /dev/urandom% ?
If that's not correct, can you please say more precisely
what "implementation" you are referring to.
> +were not widely trusted. It will return random bytes
> +only within the estimated number of bits of fresh noise in the entropy
> +pool, blocking if necessary.
> +\fI/dev/random\fP is suitable for applications that need very
> +high quality randomness, and can afford indeterminate delays.
> When the entropy pool is empty, reads from \fI/dev/random\fP will block
> until additional environmental noise is gathered.
> If
> @@ -60,18 +72,8 @@ will return -1 and
> .I errno
> will be set to
> .BR EAGAIN .
> -.LP
> -A read from the \fI/dev/urandom\fP device will not block
> -waiting for more entropy.
> -If there is not sufficient entropy, a pseudorandom number generator is used
> -to create the requested bytes.
> -As a result, in this case the returned values are theoretically vulnerable to a
> -cryptographic attack on the algorithms used by the driver.
> -Knowledge of how to do this is not available in the current unclassified
> -literature, but it is theoretically possible that such an attack may
> -exist.
> -If this is a concern in your application, use \fI/dev/random\fP
> -instead.
> +
> +The flag
> .B O_NONBLOCK
> has no effect when opening
> .IR /dev/urandom .
> @@ -82,6 +84,8 @@ for the device
> signals will not be handled until after the requested random bytes
> have been generated.
>
> +
> +
Please remove these two blank lines.
> Since Linux 3.16,
> .\" commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc
> a
> @@ -104,14 +108,11 @@ This means that it will impact the contents
> read from both files, but it will not make reads from
> \fI/dev/random\fP faster.
> .SS Usage
> -If you are unsure about whether you should use
> +The
> .IR /dev/random
> -or
> +interface is considered a legacy interface, and
I'm a little uncomfortable with the term "legacy". To me it implies
that there is *no* legitimate use of /dev/random these days. I'm
no expert on randomness, but I wonder if that is true. Is it?
If it's not, then I would prefer simply a strong statement that
"/dev/urandom is preferred and sufficient in all use cases".
> .IR /dev/urandom ,
> -then probably you want to use the latter.
> -As a general rule,
> -.IR /dev/urandom
> -should be used for everything except long-lived GPG/SSL/SSH keys.
> +is recommended for general use.
>
> If a seed file is saved across reboots as recommended below (all major
> Linux distributions have done this since 2000 at least), the output is
> -- 2.7.4
Laurent Georget also commented on this page in a mail last year.
I'm going to thread you (and the other people on this mail) into
that mail discussion in case there's something there that you
might incorporate into a revised patch.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/2] ASoC: Intel: Skylake: remaining D0i3 patches
From: Mark Brown @ 2016-11-09 15:23 UTC (permalink / raw)
To: Vinod Koul; +Cc: liam.r.girdwood, patches.audio, alsa-devel
In-Reply-To: <1478439109-22541-1-git-send-email-vinod.koul@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 277 bytes --]
On Sun, Nov 06, 2016 at 07:01:47PM +0530, Vinod Koul wrote:
> Looks like last two patches in last series posted were missed, so I am
> resending this
Please allow a reasonable time for review. More complex and less well
explained patches are going to take longer to review.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
From: Andrew Jones @ 2016-11-09 15:23 UTC (permalink / raw)
To: Andre Przywara
Cc: kvm, kvmarm, qemu-devel, qemu-arm, peter.maydell, marc.zyngier,
eric.auger, pbonzini, alex.bennee, christoffer.dall
In-Reply-To: <b4fcac1f-2cc5-09c3-0cab-71f5aaa3e7e1@arm.com>
On Wed, Nov 09, 2016 at 02:43:53PM +0000, Andre Przywara wrote:
> Hi,
>
> On 09/11/16 13:08, Andrew Jones wrote:
> > On Wed, Nov 09, 2016 at 12:35:48PM +0000, Andre Przywara wrote:
> > [...]
> >>> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
> >>> new file mode 100644
> >>> index 000000000000..03321f8c860f
> >>> --- /dev/null
> >>> +++ b/lib/arm/asm/gic-v3.h
> >>> @@ -0,0 +1,92 @@
> >>> +/*
> >>> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
> >>> + *
> >>> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> >>> + *
> >>> + * This work is licensed under the terms of the GNU LGPL, version 2.
> >>> + */
> >>> +#ifndef _ASMARM_GIC_V3_H_
> >>> +#define _ASMARM_GIC_V3_H_
> >>> +
> >>> +#ifndef _ASMARM_GIC_H_
> >>> +#error Do not directly include <asm/gic-v3.h>. Include <asm/gic.h>
> >>> +#endif
> >>> +
> >>> +#define GICD_CTLR 0x0000
> >>> +#define GICD_TYPER 0x0004
> >>
> >> So if we share the distributor register definition with GICv2, these
> >> shouldn't be here, but in gic.h.
> >> But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
> >>
> >> Now this gets interesting with your wish to both share the definitions
> >> for the GICv2 and GICv3 distributors, but also stick to the names the
> >> kernel uses (because they differ between the two) ;-)
> >> So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
> >> for instance.
> >
> > Well, we just have the same offset with two names (giving us two
> > symbols to grep). I put them here, vs. asm/gic.h, because the kernel
> > only uses theses symbols for gicv3. Now, nothing stops a unit test
> > from using them with gicv2 tests, though, because unit tests include
> > gic.h, which includes both gic-v2.h and gic-v3.h, and thus it gets
> > both. I know, it's sounding messy... Shouldn't we post some churn to
> > the kernel? :-)
>
> Well, on top of that the distributor registers are slightly different
> (check CTLR and TYPER, for instance). So it's churn plus a stretch, I
> guess Marc won't like that.
>
> So if greppability is important, should we revert to separate
> definitions in separate header files then, like in v3?
> I don't think we actually share _code_ between the two GIC revisions, do we?
>
> > Note, I tried to only add defines to asm/gic.h that are actually
> > shared in the kernel between v2 and v3, e.g. GIC_DIST_ENABLE_SET.
>
> Huh? GICv3 uses GICD_ISENABLER for that register.
drivers/irqchip/irq-gic-common.c:gic_cpu_config uses it, along with
GICD_INT_DEF_PRI_X4 and GIC_DIST_PRI. But I guess those are the only
shared ones duplicated here so far, so I was wrong to say the two
below were the only two not shared.
>
> > Actually, GIC_DIST_CTRL and GIC_DIST_CTR may be the only exceptions
> > we have so far.
>
> Note that it's GIC_DIST_CTLR (L and R swapped), one reason more to dump
> _CTR ;-)
Yeah, I noticed that too, craziness. OK, I won't fight for the
greppability argument too hard. Actually, you'll likely be the
one doing the grepping when you go fix the driver :-) If you'd
prefer we only use one set of defines (the better, modern ones),
then for v5 that's what I'll do.
>
> >>
> >>> +#define GICD_IGROUPR 0x0080
> >>> +
> >>> +#define GICD_CTLR_RWP (1U << 31)
> >>> +#define GICD_CTLR_ARE_NS (1U << 4)
> >>> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
> >>> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
> >>> +
> >>> +#define GICR_TYPER 0x0008
> >>> +#define GICR_IGROUPR0 GICD_IGROUPR
> >>> +#define GICR_TYPER_LAST (1U << 4)
> >>> +
> >>> +
> >>> +#include <asm/arch_gicv3.h>
> >>> +
> >>> +#ifndef __ASSEMBLY__
> >>> +#include <asm/setup.h>
> >>> +#include <asm/smp.h>
> >>> +#include <asm/processor.h>
> >>> +#include <asm/io.h>
> >>> +
> >>> +struct gicv3_data {
> >>> + void *dist_base;
> >>> + void *redist_base[NR_CPUS];
> >>> + unsigned int irq_nr;
> >>> +};
> >>> +extern struct gicv3_data gicv3_data;
> >>> +
> >>> +#define gicv3_dist_base() (gicv3_data.dist_base)
> >>> +#define gicv3_redist_base() (gicv3_data.redist_base[smp_processor_id()])
> >>> +#define gicv3_sgi_base() (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
> >>> +
> >>> +extern int gicv3_init(void);
> >>> +extern void gicv3_enable_defaults(void);
> >>> +
> >>> +static inline void gicv3_do_wait_for_rwp(void *base)
> >>> +{
> >>> + int count = 100000; /* 1s */
> >>> +
> >>> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
> >>> + if (!--count) {
> >>> + printf("GICv3: RWP timeout!\n");
> >>> + abort();
> >>> + }
> >>> + cpu_relax();
> >>> + udelay(10);
> >>> + };
> >>> +}
> >>> +
> >>> +static inline void gicv3_dist_wait_for_rwp(void)
> >>> +{
> >>> + gicv3_do_wait_for_rwp(gicv3_dist_base());
> >>> +}
> >>> +
> >>> +static inline void gicv3_redist_wait_for_rwp(void)
> >>> +{
> >>> + gicv3_do_wait_for_rwp(gicv3_redist_base());
> >>> +}
> >>> +
> >>> +static inline u32 mpidr_compress(u64 mpidr)
> >>> +{
> >>> + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
> >>> +
> >>> + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
> >>> + return compressed;
> >>> +}
> >>> +
> >>> +static inline u64 mpidr_uncompress(u32 compressed)
> >>> +{
> >>> + u64 mpidr = ((u64)compressed >> 24) << 32;
> >>> +
> >>> + mpidr |= compressed & MPIDR_HWID_BITMASK;
> >>> + return mpidr;
> >>> +}
> >>> +
> >>> +#endif /* !__ASSEMBLY__ */
> >>> +#endif /* _ASMARM_GIC_V3_H_ */
> >>> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> >>> index 328e078a9ae1..4897bc592cdd 100644
> >>> --- a/lib/arm/asm/gic.h
> >>> +++ b/lib/arm/asm/gic.h
> >>> @@ -7,6 +7,7 @@
> >>> #define _ASMARM_GIC_H_
> >>>
> >>> #include <asm/gic-v2.h>
> >>> +#include <asm/gic-v3.h>
> >>>
> >>> #define GIC_CPU_CTRL 0x00
> >>> #define GIC_CPU_PRIMASK 0x04
> >>> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
> >>> index 91d78c9a0cc2..af58a11ea13e 100644
> >>> --- a/lib/arm/gic.c
> >>> +++ b/lib/arm/gic.c
> >>> @@ -8,9 +8,11 @@
> >>> #include <asm/io.h>
> >>>
> >>> struct gicv2_data gicv2_data;
> >>> +struct gicv3_data gicv3_data;
> >>>
> >>> /*
> >>> * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> >>> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> >>> */
> >>> static bool
> >>> gic_get_dt_bases(const char *compatible, void **base1, void **base2)
> >>> @@ -48,10 +50,18 @@ int gicv2_init(void)
> >>> &gicv2_data.dist_base, &gicv2_data.cpu_base);
> >>> }
> >>>
> >>> +int gicv3_init(void)
> >>> +{
> >>> + return gic_get_dt_bases("arm,gic-v3", &gicv3_data.dist_base,
> >>> + &gicv3_data.redist_base[0]);
> >>> +}
> >>> +
> >>> int gic_init(void)
> >>> {
> >>> if (gicv2_init())
> >>> return 2;
> >>> + else if (gicv3_init())
> >>> + return 3;
> >>> return 0;
> >>> }
> >>>
> >>> @@ -73,3 +83,49 @@ void gicv2_enable_defaults(void)
> >>> writel(GICC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
> >>> writel(GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
> >>> }
> >>> +
> >>> +void gicv3_set_redist_base(void)
> >>> +{
> >>> + u32 aff = mpidr_compress(get_mpidr());
> >>> + void *ptr = gicv3_data.redist_base[0];
> >>> + u64 typer;
> >>> +
> >>> + do {
> >>> + typer = gicv3_read_typer(ptr + GICR_TYPER);
> >>> + if ((typer >> 32) == aff) {
> >>> + gicv3_redist_base() = ptr;
> >>> + return;
> >>> + }
> >>> + ptr += SZ_64K * 2; /* skip RD_base and SGI_base */
> >>> + } while (!(typer & GICR_TYPER_LAST));
> >>> + assert(0);
> >>> +}
> >>> +
> >>> +void gicv3_enable_defaults(void)
> >>> +{
> >>> + void *dist = gicv3_dist_base();
> >>> + void *sgi_base;
> >>> + unsigned int i;
> >>> +
> >>> + gicv3_data.irq_nr = GICD_TYPER_IRQS(readl(dist + GICD_TYPER));
> >>> + if (gicv3_data.irq_nr > 1020)
> >>> + gicv3_data.irq_nr = 1020;
> >>> +
> >>> + writel(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
> >>> + dist + GICD_CTLR);
> >>> + gicv3_dist_wait_for_rwp();
> >>> +
> >>> + if (!gicv3_redist_base())
> >>> + gicv3_set_redist_base();
> >>> + sgi_base = gicv3_sgi_base();
> >>> +
> >>> + writel(~0, sgi_base + GICR_IGROUPR0);
> >>
> >> This is mixing redist setup with distributor setup. Is it that what you
> >> meant with:
> >> " - simplify enable by not caring if we reinit the distributor [drew]"?
> >
> > Yes, but, TBH, I wasn't sure I could get away with it. I tested and it
> > worked, and I figured you'd yell at me if I was wrong :-)
> >
> >>
> >> Also if you set the group for the SGIs, you should set it for SPIs as
> >> well (like the kernel does). This was done in v3 of the series.
> >
> > OK, I was also simplifying by removing everything and then adding stuff
> > back until it worked :-) I can certainly add this back for completeness
> > though.
>
> So you did need IGROUP0?
At least with TCG, yes. When I removed it and quick tested on my x86
notebook the gic test hung. I didn't try to debug, I just added stuff
until it worked...
>
> Actually the VGIC implements a single security state, where those
> registers are supposed to be RAZ/WI, if I get the spec correctly.
> And KVM implements them as RAO/WI, both for GICR_IGROUPR0 and GICD_IGROUPRn.
> But the kernel sets both of them up (because it drives real hardware),
> so I'd trust Marc's wisdom more here ;-)
> If we don't need this GROUPR setup for proper functionality, we could
> move it from the generic setup into an actual test.
As I need GICR_IGROUP0, I'll bring GICD_IGROUPRn back too.
>
> >> What about you finish the per-CPU setup first, then bail out with:
> >>
> >> if (smp_processor_id() != 0)
> >> return;
> >>
> >> and then do the distributor setup (only on the first core).
> >
> > Sure, if it's necessary. I actually like not having to worry about
> > a particular core or a particular order/number of times this enable
> > gets called. Does it hurt to just do it each time?
>
> Shouldn't really, so we could let it stay in there until someone
> complains ...
Thanks,
drew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.