Re: [PATCH] virtio_mmio: add ACPI probing
On Tue, Jul 28, 2015 at 10:44:02AM +0100, Graeme Gregory wrote:
Added the match table and pointers for ACPI probing to the driver.
This uses the same identifier for virt devices as being used for qemu
ARM64 ACPI support.
http://git.linaro.org/people/shannon.zhao/qemu.git/commit/d0bf1955a3ecbab4b51d46f8c5dda02b7e14a17e
Signed-off-by: Graeme Gregory graeme.greg...@linaro.org
To summarize, let's wait a bit with this until QEMU 2.4
with the relevant code is out, to make sure ID does not
change.
---
drivers/virtio/virtio_mmio.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 10189b5..f499d9d 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -58,6 +58,7 @@
#define pr_fmt(fmt) virtio-mmio: fmt
+#include linux/acpi.h
#include linux/highmem.h
#include linux/interrupt.h
#include linux/io.h
@@ -732,12 +733,21 @@ static struct of_device_id virtio_mmio_match[] = {
};
MODULE_DEVICE_TABLE(of, virtio_mmio_match);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
+ { LNRO0005, },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
+#endif
+
static struct platform_driver virtio_mmio_driver = {
.probe = virtio_mmio_probe,
.remove = virtio_mmio_remove,
.driver = {
.name = virtio-mmio,
.of_match_table = virtio_mmio_match,
+ .acpi_match_table = ACPI_PTR(virtio_mmio_acpi_match),
},
};
--
2.1.4
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v2] arm: change vendor ID for virtio-mmio
ACPI spec 5.0 allows the use of PCI vendor IDs.
Since we have one for virtio, it seems neater to use that
rather than LNRO. For the device ID, use 103F which is a legacy ID that
isn't used in virtio PCI spec - seems to make sense since virtio-mmio is
a legacy device but we don't know the correct device type.
Guests should probably match everything in the range 1000-103F
(just like legacy pci drivers do) which will allow us to pass in the
actual ID in the future if we want to.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/arm/virt-acpi-build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index f365140..dea61ba 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope,
for (i = 0; i num; i++) {
Aml *dev = aml_device(VR%02u, i);
-aml_append(dev, aml_name_decl(_HID, aml_string(LNRO0005)));
+aml_append(dev, aml_name_decl(_HID, aml_string(1AF4103F)));
aml_append(dev, aml_name_decl(_UID, aml_int(i)));
Aml *crs = aml_resource_template();
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_mmio: add ACPI probing
On 28 July 2015 at 11:33, G Gregory graeme.greg...@linaro.org wrote: We assigned LNRO in ASWG to avoid collisions with our prototypes/real platforms so it makes sense to me to switch to QEMU. So just to check, if we switch virtio-mmio from an LNRO0005 ID to a QEMU ID we aren't going to break any existing widely shipped or deployed code, right? If we can change the ID without breaking anything significant then I think the QEMU ID makes more sense; but it doesn't really gain us much beyond tidiness. PS: https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt uses virtio-mmio and LNRO0005 as its code example, so if we change this then it might be nice to update the docs as a followup. thanks -- PMM ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_mmio: add ACPI probing
On Wed, Jul 29, 2015 at 06:52:29PM +0100, Peter Maydell wrote:
On 28 July 2015 at 11:33, G Gregory graeme.greg...@linaro.org wrote:
We assigned LNRO in ASWG to avoid collisions with our prototypes/real
platforms so it makes sense to me to switch to QEMU.
So just to check, if we switch virtio-mmio from an LNRO0005 ID
to a QEMU ID we aren't going to break any existing widely
shipped or deployed code, right?
If we can change the ID without breaking anything significant
then I think the QEMU ID makes more sense; but it doesn't
really gain us much beyond tidiness.
PS: https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt
uses virtio-mmio and LNRO0005 as its code example, so if
we change this then it might be nice to update the docs
as a followup.
thanks
-- PMM
So this is the proposed patch. I agree it's merely about tidyness.
Pls ack or nack - we need to decide before 2.4 is out.
--
arm: change vendor ID for virtio-mmio
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index f365140..d10bd69 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -145,7 +145,7 @@ static void acpi_dsdt_add_virtio(Aml *scope,
for (i = 0; i num; i++) {
Aml *dev = aml_device(VR%02u, i);
-aml_append(dev, aml_name_decl(_HID, aml_string(LNRO0005)));
+aml_append(dev, aml_name_decl(_HID, aml_string(QEMU0005)));
aml_append(dev, aml_name_decl(_UID, aml_int(i)));
Aml *crs = aml_resource_template();
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] enable migration of driver pages
2015-07-29 오후 9:46에 Daniel Vetter 이(가) 쓴 글: On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote: On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote: On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote: My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. The primary motivation of this series is to reduce fragmentation by allowing more kernel pages to be moved. Conceptually that is a worthwhile goal but there should be at least one major in-kernel user and while balloon pages were a good starting point, I think we really need to see what the zram changes look like at the same time. I think gpu drivers really would be the perfect candidate for compacting kernel page allocations. And this also seems the primary motivation for this patch series, so I think that's really what we should use to judge these patches. Of course then there's the seemingly eternal chicken/egg problem of upstream gpu drivers for SoCs :( I recognised that the driver he had modified was not an in-tree user so it did not really help the review or the design. I did not think it was very fair to ask that an in-tree GPU driver be converted when it would not help the embedded platform of interest. Converting zram is both a useful illustration of the aops requirements and is expected to be beneficial on the embedded platform. Now, if a GPU driver author was willing to convert theirs as an example then that would be useful! Well my concern is more with merging infrastructure to upstream for drivers which aren't upstream and with no plan to make that happen anytime soon. Seems like just offload a bit to me ... but in the end core mm isn't my thing so not my decision. -Daniel I get idea from the out-tree driver but this infrastructure will be useful for zram and balloon. That is agreed by the maintainers of each driver. I'm currently accepting feedbacks from balloon and zram and trying to be applicable for them. Of course I hope there will be more application. It'll be more useful if it has more application. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API
On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on most modern
non-virtual platforms, PPC included.
Are there many virtio physical devices out there ? We are talking about
a virtio flag right ? Or have you been considering something else ?
Yes, virtio flag. I dislike having a virtio flag at all, but so far
no one has come up with any better ideas. If there was a reliable,
cross-platform mechanism for per-device PCI bus properties, I'd be all
for using that instead.
No, a virtio flag doesn't make sense.
Blindly using system memory is a bug in QEMU; it has to be fixed to use
the right address space, and then whatever the system provides to
describe the right address space can be used (like the DMAR table on x86).
On PPC I suppose you could use the host bridge's device tree? If you
need a hook, you can add a
bool virtio_should_bypass_iommu(void)
{
/* lookup something in the device tree?!? */
}
EXPORT_SYMBOL_GPL(virtio_should_bypass_iommu);
in some pseries.c file, and in the driver:
static bool virtio_bypass_iommu(void)
{
bool (*fn)(void);
fn = symbol_get(virtio_should_bypass_iommu);
return fn fn();
}
Awful, but that's what this thing is.
Paolo
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API
On 2015-07-29 01:21, Benjamin Herrenschmidt wrote: On Tue, 2015-07-28 at 15:43 -0700, Andy Lutomirski wrote: New QEMU always advertises this feature flag. If iommu=on, QEMU's virtio devices refuse to work unless the driver acknowledges the flag. This should be configurable. Advertisement of that flag must be configurable, or we won't be able to run older guests anymore which don't know it, thus will reject it. The only precondition: there must be no IOMMU if we turn it off. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API
On 2015-07-29 10:17, Paolo Bonzini wrote: On 29/07/2015 02:47, Andy Lutomirski wrote: If new kernels ignore the IOMMU for devices that don't set the flag and there are physical devices that already exist and don't set the flag, then those devices won't work reliably on most modern non-virtual platforms, PPC included. Are there many virtio physical devices out there ? We are talking about a virtio flag right ? Or have you been considering something else ? Yes, virtio flag. I dislike having a virtio flag at all, but so far no one has come up with any better ideas. If there was a reliable, cross-platform mechanism for per-device PCI bus properties, I'd be all for using that instead. No, a virtio flag doesn't make sense. That will create the risk of subtly breaking old guests over new setups. I wouldn't suggest this. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API
On Wed, 2015-07-29 at 10:17 +0200, Paolo Bonzini wrote:
On 29/07/2015 02:47, Andy Lutomirski wrote:
If new kernels ignore the IOMMU for devices that don't set the flag
and there are physical devices that already exist and don't set the
flag, then those devices won't work reliably on most modern
non-virtual platforms, PPC included.
Are there many virtio physical devices out there ? We are talking about
a virtio flag right ? Or have you been considering something else ?
Yes, virtio flag. I dislike having a virtio flag at all, but so far
no one has come up with any better ideas. If there was a reliable,
cross-platform mechanism for per-device PCI bus properties, I'd be all
for using that instead.
No, a virtio flag doesn't make sense.
It wouldn't if we were creating virtio from scratch.
However we have to be realistic here, we are contending with existing
practices and implementation. The fact is qemu *does* bypass any iommu
and has been doing so for a long time, *and* the guest drivers are
written today *also* bypassing all DMA mapping mechanisms and just
passing everything accross.
So if it's a bug, it's a bug on both sides of the fence. We are no
longer in bug fixing territory here, it's a fundamental change of ABI.
The ABI might not be what was intended (but that's arguable, see below),
but it is that way.
Arguably it was even known and considered a *feature* by some (including
myself) at the time. It somewhat improved performances on archs where
otherwise every page would have to be mapped/unmapped in guest iommu. In
fact, it also makes vhost a lot easier.
So I disagree, it's de-facto a feature (even if unintended) of the
existing virtio implementations and changing that would be a major
interface change, and thus should be exposed as such.
Blindly using system memory is a bug in QEMU; it has to be fixed to use
the right address space, and then whatever the system provides to
describe the right address space can be used (like the DMAR table on x86).
Except that it's not so easy.
For example, on PPC PAPR guests, there is no such thing as a no IOMMU
space, the concept doesn't exist. So we have at least three things to
deal with:
- Existing guests, so we must preserve the existing behaviour for
backward compatibility.
- vhost is made more complex because it now needs to be informed of the
guest iommu updates
- New guests have the new driver that knows how to map and unmap
would have a performance loss unless some mechanism to create a no
iommu space exists which for us would need to be added. Either that or
we rely on DDW which is a way for a guest to create a permanent mapping
of its entire address space in an IOMMU but that incur a significant
waste of host kernel memory.
On PPC I suppose you could use the host bridge's device tree? If you
need a hook, you can add a
No because we can mix and match virtio and other devices on the same
host bridge. Unless we put a property that only applies to virtio
children of the host bridge.
bool virtio_should_bypass_iommu(void)
{
/* lookup something in the device tree?!? */
}
EXPORT_SYMBOL_GPL(virtio_should_bypass_iommu);
in some pseries.c file, and in the driver:
static bool virtio_bypass_iommu(void)
{
bool (*fn)(void);
fn = symbol_get(virtio_should_bypass_iommu);
return fn fn();
}
Awful, but that's what this thing is.
Ben.
Paolo
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio_mmio: add ACPI probing
On Wed, Jul 29, 2015 at 10:01:35AM +0800, Shannon Zhao wrote: On 2015/7/29 5:10, Peter Maydell wrote: On 28 July 2015 at 21:28, G Gregory graeme.greg...@linaro.org wrote: On 28 July 2015 at 21:12, Peter Maydell peter.mayd...@linaro.org wrote: Mmm. I'm not terribly happy about stuff being in QEMU before the ACPI spec for it has been finalised. We should not be picking stuff randomly on the fly... If we want to fix the ACPI IDs QEMU is using for 2.4 then we really need to do that now (ie within the next day or two). It is upto the owner of the QEMU prefix to allocate numbers. This is not an issue for ACPI spec at all. I mean the specification for how this device should be advertised in an ACPI table. I don't care whether that's an official ACPI consortium thing or something less official. The table is constructed by QEMU and read by the kernel (and possibly also by UEFI?), so everybody needs to agree on what the string is... I agree with Peter. Maybe we should record these IDs at some place. Right. And it should apply even if you keep using LNRO. Pls create docs/specs/acpi_ids.txt and list them there. For simplicity, I'd just replace LNRO with QEMU. Since QEMU is owner of this device and we register QEMU in ASWG, the official ID can be assigned by QEMU and the ID could(or should) be QEMU. But what's the exact ID for this virtio-mmio? That's what we need to agree on and record. So far we only had PVPANIC with ACPI ID QEMU0001. P.S. I don't see QEMU in the list of approved Vendor IDs for ACPI. http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf http://www.uefi.org/sites/default/files/resources/ACPIID_List.pdf Should appear there any day now. -- Shannon ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] enable migration of driver pages
On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote: On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote: My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. The primary motivation of this series is to reduce fragmentation by allowing more kernel pages to be moved. Conceptually that is a worthwhile goal but there should be at least one major in-kernel user and while balloon pages were a good starting point, I think we really need to see what the zram changes look like at the same time. I think gpu drivers really would be the perfect candidate for compacting kernel page allocations. And this also seems the primary motivation for this patch series, so I think that's really what we should use to judge these patches. Of course then there's the seemingly eternal chicken/egg problem of upstream gpu drivers for SoCs :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/4] enable migration of driver pages
On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote: On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote: On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote: On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote: My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. The primary motivation of this series is to reduce fragmentation by allowing more kernel pages to be moved. Conceptually that is a worthwhile goal but there should be at least one major in-kernel user and while balloon pages were a good starting point, I think we really need to see what the zram changes look like at the same time. I think gpu drivers really would be the perfect candidate for compacting kernel page allocations. And this also seems the primary motivation for this patch series, so I think that's really what we should use to judge these patches. Of course then there's the seemingly eternal chicken/egg problem of upstream gpu drivers for SoCs :( I recognised that the driver he had modified was not an in-tree user so it did not really help the review or the design. I did not think it was very fair to ask that an in-tree GPU driver be converted when it would not help the embedded platform of interest. Converting zram is both a useful illustration of the aops requirements and is expected to be beneficial on the embedded platform. Now, if a GPU driver author was willing to convert theirs as an example then that would be useful! Well my concern is more with merging infrastructure to upstream for drivers which aren't upstream and with no plan to make that happen anytime soon. Seems like just offload a bit to me ... but in the end core mm isn't my thing so not my decision. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
