On 8/20/20 7:19 PM, Tian Tao wrote:
> Use kobj_to_dev() instead of container_of()
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master v5.9-rc1 next-20200821]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Fri, Aug 21, 2020 at 09:19:15AM +0800, Tian Tao wrote:
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Tian Tao
> ---
> drivers/block/virtio_blk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP
On Wed, 19 Aug 2020 18:23:17 +0200
Pierre Morel wrote:
> An architecture may restrict host access to guest memory.
"e.g. IBM s390 Secure Execution or AMD SEV"
Just to make clearer what you are referring to?
>
> Provide a new Kconfig entry the architecture can select,
>
Signed-off-by: kernel test robot
---
vdpa_sim.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 89854e17c3c27b..ff6c9fd8d879bd 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master v5.9-rc1 next-20200821]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 2020-08-21 13:59, Cornelia Huck wrote:
On Wed, 19 Aug 2020 18:23:17 +0200
Pierre Morel wrote:
An architecture may restrict host access to guest memory.
"e.g. IBM s390 Secure Execution or AMD SEV"
Just to make clearer what you are referring to?
yes, thanks
Provide a new Kconfig
On Wed, 19 Aug 2020 18:23:18 +0200
Pierre Morel wrote:
> If protected virtualization is active on s390, VIRTIO has retricted
s/retricted/only restricted/
> access to the guest memory.
> Define CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS and export
> arch_has_restricted_virtio_memory_access
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master v5.9-rc1 next-20200821]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Signed-off-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 62d640327145..89854e17c3c2 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++
This patch introduces a new ioctl for vhost-vdpa device that can
report the iova range by the device.
For device that implements get_iova_range() method, we fetch it from
the vDPA device. If device doesn't implement get_iova_range() but
depends on platform IOMMU, we will query via
On 2020-08-21 14:05, Cornelia Huck wrote:
On Wed, 19 Aug 2020 18:23:18 +0200
Pierre Morel wrote:
If protected virtualization is active on s390, VIRTIO has retricted
s/retricted/only restricted/
access to the guest memory.
Define CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS and
This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective
merging of memory resources" [1]
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory
virtio-mem adds memory in memory block granularity, to be able to
remove it in the same granularity again later, and to grow slowly on
demand. This, however, results in quite a lot of resources when
adding a lot of memory. Resources are effectively stored in a list-based
tree. Having a lot of
Let's reuse the new mechanism to merge system ram resources below the
root. We are the only one hotplugging system ram (e.g., DIMMs don't apply),
so this is safe to be used.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Roger Pau Monné
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected system ram
resources - then, we'll trigger that case more frequently on memory
hotunplug.
In general, this function is already unlikely to fail. When we remove
memory,
Let's use the new mechanism to merge system ram resources below the
root. We are the only one hotplugging system ram, e.g., DIMMs don't apply,
so this is safe to be used.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Pankaj
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs,
Add struct definitions for describing endpoints managed by the
virtio-iommu. When VIRTIO_IOMMU_F_TOPOLOGY is offered, an array of
virtio_iommu_topo_* structures in config space describes the endpoints,
identified either by their PCI BDF or their physical MMIO address.
Signed-off-by: Jean-Philippe
Hardware platforms usually describe the IOMMU topology using either
device-tree pointers or vendor-specific ACPI tables. For virtual
platforms that don't provide a device-tree, the virtio-iommu device
contains a description of the endpoints it manages. That information
allows us to probe
Add a topology description to the virtio-iommu driver and enable x86
platforms.
Since [v2] we have made some progress on adding ACPI support for
virtio-iommu, which is the preferred boot method on x86. It will be a
new vendor-agnostic table describing para-virtual topologies in a
minimal format.
Platforms without device-tree nor ACPI can provide a topology
description embedded into the virtio config space. Parse it.
Use PCI FIXUP to probe the config space early, because we need to
discover the topology before any DMA configuration takes place, and the
virtio driver may be loaded much
With the built-in topology description in place, x86 platforms can now
use the virtio-iommu.
Architectures that use the generic iommu_dma_ops should normally select
CONFIG_IOMMU_DMA themselves (from arch/*/Kconfig). Since not all x86
drivers have been converted yet, it's currently up to the IOMMU
To support topology description from ACPI and from the builtin
description, add helpers to keep track of I/O topology descriptors.
To ease re-use of the helpers by other drivers and future ACPI
extensions, use the "virt_" prefix rather than "virtio_" when naming
structs and functions.
Before adding new files to the virtio-iommu driver, move it to its own
subfolder, similarly to other IOMMU drivers.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Makefile| 3 +--
drivers/iommu/virtio/Makefile | 2 ++
drivers/iommu/{ =>
Hi All:
This series introduces API for reporing IOVA range. This is a must for
userspace to work correclty:
- for the process that uses vhost-vDPA directly to properly allocate
IOVA
- for VM(qemu), when vIOMMU is not enabled, fail early if GPA is out
of range
- for VM(qemu), when vIOMMU is
This patch introduce a config op to get valid iova range from the vDPA
device.
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index eae0bfd87d91..30bc7a7223bb 100644
---
Hi Jason,
I love your patch! Perhaps something to improve:
[auto build test WARNING on vhost/linux-next]
[also build test WARNING on linus/master v5.9-rc1 next-20200821]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 8/21/20 3:50 PM, Nathan Chancellor wrote:
> Clang warns several times when building for 32-bit ARM along the lines
> of:
>
> drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width
> of type [-Wshift-count-overflow]
> ndev->mvdev.mlx_features |=
Clang warns several times when building for 32-bit ARM along the lines
of:
drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width
of type [-Wshift-count-overflow]
ndev->mvdev.mlx_features |= BIT(VIRTIO_F_VERSION_1);
On Fri, 21 Aug 2020 10:45:33 +0200 David Hildenbrand wrote:
> On 21.08.20 10:31, David Hildenbrand wrote:
> > On 16.08.20 14:53, David Hildenbrand wrote:
> >> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff
> >> maintained by me. This should go via the -mm tree.
> >>
> >
On Fri, Aug 21, 2020 at 04:13:19PM -0700, Randy Dunlap wrote:
> On 8/21/20 3:50 PM, Nathan Chancellor wrote:
> > Clang warns several times when building for 32-bit ARM along the lines
> > of:
> >
> > drivers/vdpa/mlx5/net/mlx5_vnet.c:1462:31: warning: shift count >= width
> > of type
On Fri, 2020-08-21 at 16:13 -0700, Randy Dunlap wrote:
> On 8/21/20 3:50 PM, Nathan Chancellor wrote:
> > Clang warns several times when building for 32-bit ARM along the lines
> > of:
The defines are quite horrible to read.
Maybe:
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 61
On 16.08.20 14:53, David Hildenbrand wrote:
> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff
> maintained by me. This should go via the -mm tree.
>
@Andrew, can we give this a churn if there are no further comments? Thanks!
--
Thanks,
David / dhildenb
Hi,
While preparing the next version I noticed I forgot to send this reply.
Better late than never I suppose...
On Tue, Apr 21, 2020 at 07:31:12AM +, Tian, Kevin wrote:
> > From: Jean-Philippe Brucker
> > Sent: Saturday, February 29, 2020 1:26 AM
> >
> > Platforms without device-tree do not
On 21.08.20 10:31, David Hildenbrand wrote:
> On 16.08.20 14:53, David Hildenbrand wrote:
>> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff
>> maintained by me. This should go via the -mm tree.
>>
>
> @Andrew, can we give this a churn if there are no further comments?
On 21.08.20 10:46, Baoquan He wrote:
> On 08/21/20 at 10:31am, David Hildenbrand wrote:
>> On 16.08.20 14:53, David Hildenbrand wrote:
>>> For 5.10. Patch #1-#4,#6 have RBs or ACKs, patch #5 is virtio-mem stuff
>>> maintained by me. This should go via the -mm tree.
>>>
>>
>> @Andrew, can we give
On Thu, Aug 20, 2020 at 08:32:51AM +0200, Jiri Slaby wrote:
> On 19. 08. 20, 15:24, Gerd Hoffmann wrote:
> > On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> >> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> >>> Exactly matches the one in the helpers.
> >>
> >> It's not that exact. The
Eric Biggers wrote:
> From: Ram Muthiah
>
> Drivers shouldn't be enabled by default unless there is a very good
> reason to do so. There doesn't seem to be any such reason for the
> virtio crypto driver, so change it to the default of 'n'.
>
> Signed-off-by: Ram Muthiah
> [EB: adjusted
Hi Mike,
On Thu, Aug 20, 2020 at 12:58:13AM +, Mike Stunes wrote:
> Yes, I still see the issue — APs are offline after boot. I’ll spend
> some time seeing if I can figure out what the problem is. Thanks!
Tom and a few others debugged another FSGSBASE issue yesterday, which I
think might also
On Fri, Aug 21, 2020 at 09:19:15AM +0800, Tian Tao wrote:
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Tian Tao
> ---
> drivers/block/virtio_blk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/virtio_blk.c
41 matches
Mail list logo
