Hi Michael, On 1/19/22 3:39 PM, Michael S. Tsirkin wrote:> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: >> This enables virtio-mem device support by allowing to enable the >> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the >> architecture. >> >> Signed-off-by: Gavin Shan <gshan at redhat.com> >> Acked-by: David Hildenbrand <david at redhat.com> >> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com> >> Acked-by: Michael S. Tsirkin <mst at redhat.com> >> --- >> v3: Pick ack-by tags from Jonathan and Michael >> --- >> drivers/virtio/Kconfig | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig >> index 34f80b7a8a64..74c8b0c7bc33 100644 >> --- a/drivers/virtio/Kconfig >> +++ b/drivers/virtio/Kconfig >> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON >> config VIRTIO_MEM >> tristate "Virtio mem driver" >> default m >> - depends on X86_64 >> + depends on X86_64 || ARM64 >> depends on VIRTIO >> depends on MEMORY_HOTPLUG >> depends on MEMORY_HOTREMOVE >> @@ -116,8 +116,9 @@ config VIRTIO_MEM >> This driver provides access to virtio-mem paravirtualized memory >> devices, allowing to hotplug and hotunplug memory. >> >> - This driver was only tested under x86-64, but should theoretically >> - work on all architectures that support memory hotplug and hotremove. >> + This driver was only tested under x86-64 and arm64, but should >> + theoretically work on all architectures that support memory hotplug >> + and hotremove. >> > > BTW isn't there a symbol saying "memory hotplug" that we can depend on? >You mean to change it like below? Actually, both looks good to me :) + This driver was only tested under x86-64 and arm64, but should + theoretically work on all architectures.>> If unsure, say M. >>Thanks, Gavin
David Hildenbrand
2022-Jan-19 08:35 UTC
[PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On 19.01.22 08:46, Gavin Shan wrote:> Hi Michael, > > On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: >> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: >>> This enables virtio-mem device support by allowing to enable the >>> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the >>> architecture. >>> >>> Signed-off-by: Gavin Shan <gshan at redhat.com> >>> Acked-by: David Hildenbrand <david at redhat.com> >>> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com> >>> Acked-by: Michael S. Tsirkin <mst at redhat.com> >>> --- >>> v3: Pick ack-by tags from Jonathan and Michael >>> --- >>> drivers/virtio/Kconfig | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig >>> index 34f80b7a8a64..74c8b0c7bc33 100644 >>> --- a/drivers/virtio/Kconfig >>> +++ b/drivers/virtio/Kconfig >>> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON >>> config VIRTIO_MEM >>> tristate "Virtio mem driver" >>> default m >>> - depends on X86_64 >>> + depends on X86_64 || ARM64 >>> depends on VIRTIO >>> depends on MEMORY_HOTPLUG >>> depends on MEMORY_HOTREMOVE >>> @@ -116,8 +116,9 @@ config VIRTIO_MEM >>> This driver provides access to virtio-mem paravirtualized memory >>> devices, allowing to hotplug and hotunplug memory. >>> >>> - This driver was only tested under x86-64, but should theoretically >>> - work on all architectures that support memory hotplug and hotremove. >>> + This driver was only tested under x86-64 and arm64, but should >>> + theoretically work on all architectures that support memory hotplug >>> + and hotremove. >>> >> >> BTW isn't there a symbol saying "memory hotplug" that we can depend on? >>You mean depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE We still need a manual opt-in from architectures, because devil's in the detail. (e.g., memblock stuff we had to adjust) -- Thanks, David / dhildenb
Michael S. Tsirkin
2022-Feb-04 13:24 UTC
[PATCH v3] drivers/virtio: Enable virtio mem for ARM64
On Wed, Jan 19, 2022 at 09:35:05AM +0100, David Hildenbrand wrote:> On 19.01.22 08:46, Gavin Shan wrote: > > Hi Michael, > > > > On 1/19/22 3:39 PM, Michael S. Tsirkin wrote: > >> On Wed, Jan 19, 2022 at 09:05:51AM +0800, Gavin Shan wrote: > >>> This enables virtio-mem device support by allowing to enable the > >>> corresponding kernel config option (CONFIG_VIRTIO_MEM) on the > >>> architecture. > >>> > >>> Signed-off-by: Gavin Shan <gshan at redhat.com> > >>> Acked-by: David Hildenbrand <david at redhat.com> > >>> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com> > >>> Acked-by: Michael S. Tsirkin <mst at redhat.com> > >>> --- > >>> v3: Pick ack-by tags from Jonathan and Michael > >>> --- > >>> drivers/virtio/Kconfig | 7 ++++--- > >>> 1 file changed, 4 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > >>> index 34f80b7a8a64..74c8b0c7bc33 100644 > >>> --- a/drivers/virtio/Kconfig > >>> +++ b/drivers/virtio/Kconfig > >>> @@ -106,7 +106,7 @@ config VIRTIO_BALLOON > >>> config VIRTIO_MEM > >>> tristate "Virtio mem driver" > >>> default m > >>> - depends on X86_64 > >>> + depends on X86_64 || ARM64 > >>> depends on VIRTIO > >>> depends on MEMORY_HOTPLUG > >>> depends on MEMORY_HOTREMOVE > >>> @@ -116,8 +116,9 @@ config VIRTIO_MEM > >>> This driver provides access to virtio-mem paravirtualized memory > >>> devices, allowing to hotplug and hotunplug memory. > >>> > >>> - This driver was only tested under x86-64, but should theoretically > >>> - work on all architectures that support memory hotplug and hotremove. > >>> + This driver was only tested under x86-64 and arm64, but should > >>> + theoretically work on all architectures that support memory hotplug > >>> + and hotremove. > >>> > >> > >> BTW isn't there a symbol saying "memory hotplug" that we can depend on? > >> > > You mean > > depends on MEMORY_HOTPLUG > depends on MEMORY_HOTREMOVE > > We still need a manual opt-in from architectures, because devil's in the > detail. (e.g., memblock stuff we had to adjust)Is there any chance of documenting some of this here? The current comment makes it look like it's just a question of whitelisting an architecture.> -- > Thanks, > > David / dhildenb