Re: [PATCH 0/9] drm: Annotate structs with __counted_by
Am 29.09.23 um 21:33 schrieb Kees Cook: On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: This is a batch of patches touching drm for preparing for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by to structs that would benefit from the annotation. [...] Since this got Acks, I figure I should carry it in my tree. Let me know if this should go via drm instead. Applied to for-next/hardening, thanks! [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by https://git.kernel.org/kees/c/a6046ac659d6 STOP! In a follow up discussion Alex and I figured out that this won't work. The value in the structure is byte swapped based on some firmware endianness which not necessary matches the CPU endianness. Please revert that one from going upstream if it's already on it's way. And because of those reasons I strongly think that patches like this should go through the DRM tree :) Regards, Christian. [2/9] drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by https://git.kernel.org/kees/c/4df33089b46f [3/9] drm/i915/selftests: Annotate struct perf_series with __counted_by https://git.kernel.org/kees/c/ffd3f823bdf6 [4/9] drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by https://git.kernel.org/kees/c/2de35a989b76 [5/9] drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by https://git.kernel.org/kees/c/188aeb08bfaa [6/9] drm/vc4: Annotate struct vc4_perfmon with __counted_by https://git.kernel.org/kees/c/59a54dc896c3 [7/9] drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by https://git.kernel.org/kees/c/5cd476de33af [8/9] drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by https://git.kernel.org/kees/c/b426f2e5356a [9/9] drm/v3d: Annotate struct v3d_perfmon with __counted_by https://git.kernel.org/kees/c/dc662fa1b0e4 Take care, ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH vhost v2 00/16] vdpa: Add support for vq descriptor mappings
On Thu, Sep 28, 2023 at 07:45:11PM +0300, Dragos Tatulea wrote: > This patch series adds support for vq descriptor table mappings which > are used to improve vdpa live migration downtime. The improvement comes > from using smaller mappings which take less time to create and destroy > in hw. > > The first part adds the vdpa core changes from Si-Wei [0]. > > The second part adds support in mlx5_vdpa: > - Refactor the mr code to be able to cleanly add descriptor mappings. > - Add hardware descriptor mr support. > - Properly update iotlb for cvq during ASID switch. > > Changes in v2: > > - The "vdpa/mlx5: Enable hw support for vq descriptor mapping" change > was split off into two patches to avoid merge conflicts into the tree > of Linus. > > The first patch contains only changes for mlx5_ifc.h. This must be > applied into the mlx5-next tree [1] first. Once this patch is applied > on mlx5-next, the change has to be pulled fom mlx5-next into the vhost > tree and only then the remaining patches can be applied. > > [0] > https://lore.kernel.org/virtualization/1694248959-13369-1-git-send-email-si-wei@oracle.com > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-next > > Dragos Tatulea (13): > vdpa/mlx5: Expose descriptor group mkey hw capability I prepared shared branch with this patch. https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git/log/?h=mlx5-vhost Thanks ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: (subset) [PATCH vhost v2 00/16] vdpa: Add support for vq descriptor mappings
On Thu, 28 Sep 2023 19:45:11 +0300, Dragos Tatulea wrote: > This patch series adds support for vq descriptor table mappings which > are used to improve vdpa live migration downtime. The improvement comes > from using smaller mappings which take less time to create and destroy > in hw. > > The first part adds the vdpa core changes from Si-Wei [0]. > > [...] Applied, thanks! [01/16] vdpa/mlx5: Expose descriptor group mkey hw capability https://git.kernel.org/rdma/rdma/c/d424348b060d87 Best regards, -- Leon Romanovsky ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
RE: [PATCH vfio 11/11] vfio/virtio: Introduce a vfio driver over virtio devices
> From: Michael S. Tsirkin
> Sent: Friday, September 22, 2023 9:23 PM
> > +static int virtiovf_pci_probe(struct pci_dev *pdev,
> > + const struct pci_device_id *id) {
> > + const struct vfio_device_ops *ops = &virtiovf_acc_vfio_pci_ops;
> > + struct virtiovf_pci_core_device *virtvdev;
> > + int ret;
> > +
> > + if (pdev->is_virtfn && virtiovf_support_legacy_access(pdev) &&
> > + !virtiovf_bar0_exists(pdev) && pdev->msix_cap)
>
> I see this is the reason you set MSIX to true. But I think it's a
> misunderstanding -
> that true means MSIX is enabled by guest, not that it exists.
Msix check here just looks a sanity check to make sure that guest can enable
msix.
The msix enable check should be in the read()/write() calls to decide which AQ
command to choose from,
i.e. to access common config or device config as written in the virtio spec.
Yishai please fix the read() write() calls to dynamically consider the offset
of 24/20 based on the msix enabled state.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] virtio_balloon: Fix endless deflation and inflation on arm64
On 25.09.23 01:58, Gavin Shan wrote:
Hi David and Michael,
On 8/31/23 11:10, Gavin Shan wrote:
The deflation request to the target, which isn't unaligned to the
guest page size causes endless deflation and inflation actions. For
example, we receive the flooding QMP events for the changes on memory
balloon's size after a deflation request to the unaligned target is
sent for the ARM64 guest, where we have 64KB base page size.
/home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \
-accel kvm -machine virt,gic-version=host -cpu host \
-smp maxcpus=8,cpus=8,sockets=2,clusters=2,cores=2,threads=1 \
-m 1024M,slots=16,maxmem=64G \
-object memory-backend-ram,id=mem0,size=512M \
-object memory-backend-ram,id=mem1,size=512M \
-numa node,nodeid=0,memdev=mem0,cpus=0-3 \
-numa node,nodeid=1,memdev=mem1,cpus=4-7 \
: \
-device virtio-balloon-pci,id=balloon0,bus=pcie.10
{ "execute" : "balloon", "arguments": { "value" : 1073672192 } }
{"return": {}}
{"timestamp": {"seconds": 1693272173, "microseconds": 88667}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272174, "microseconds": 89704}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272175, "microseconds": 90819}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272176, "microseconds": 91961}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272177, "microseconds": 93040}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
{"timestamp": {"seconds": 1693272178, "microseconds": 94117}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
{"timestamp": {"seconds": 1693272179, "microseconds": 95337}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272180, "microseconds": 96615}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
{"timestamp": {"seconds": 1693272181, "microseconds": 97626}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272182, "microseconds": 98693}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
{"timestamp": {"seconds": 1693272183, "microseconds": 99698}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272184, "microseconds": 100727}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272185, "microseconds": 90430}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{"timestamp": {"seconds": 1693272186, "microseconds": 102999}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
:
Fix it by aligning the target up to the guest page size, 64KB in this
specific case. With this applied, no flooding QMP events are observed
and the memory balloon's size can be stablizied to 0x3ffe soon
after the deflation request is sent.
{ "execute" : "balloon", "arguments": { "value" : 1073672192 } }
{"return": {}}
{"timestamp": {"seconds": 1693273328, "microseconds": 793075}, \
"event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
{ "execute" : "query-balloon" }
{"return": {"actual": 1073610752}}
Signed-off-by: Gavin Shan
Tested-by: Zhenyu Zhang
---
v2: Align @num_pages up to the guest page size in towards_target()
directly as David suggested.
---
drivers/virtio/virtio_balloon.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
If the patch looks good, could you please merge this to Linux 6.6.rc4 since
it's something needed by our downstream. I hope it can land upstream as early
as possible, thanks a lot.
@MST, I cannot spot it in your usual vhost git yet. Should I pick it up
or what are your plans?
--
Cheers,
David / dhildenb
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm: Annotate structs with __counted_by
On Mon, Oct 2, 2023 at 5:20 AM Christian König wrote: > > Am 29.09.23 um 21:33 schrieb Kees Cook: > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: > >> This is a batch of patches touching drm for preparing for the coming > >> implementation by GCC and Clang of the __counted_by attribute. Flexible > >> array members annotated with __counted_by can have their accesses > >> bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array > >> indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). > >> > >> As found with Coccinelle[1], add __counted_by to structs that would > >> benefit from the annotation. > >> > >> [...] > > Since this got Acks, I figure I should carry it in my tree. Let me know > > if this should go via drm instead. > > > > Applied to for-next/hardening, thanks! > > > > [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with > > __counted_by > >https://git.kernel.org/kees/c/a6046ac659d6 > > STOP! In a follow up discussion Alex and I figured out that this won't work. > > The value in the structure is byte swapped based on some firmware > endianness which not necessary matches the CPU endianness. SMU10 is APU only so the endianess of the SMU firmware and the CPU will always match. Alex > > Please revert that one from going upstream if it's already on it's way. > > And because of those reasons I strongly think that patches like this > should go through the DRM tree :) > > Regards, > Christian. > > > [2/9] drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by > >https://git.kernel.org/kees/c/4df33089b46f > > [3/9] drm/i915/selftests: Annotate struct perf_series with __counted_by > >https://git.kernel.org/kees/c/ffd3f823bdf6 > > [4/9] drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by > >https://git.kernel.org/kees/c/2de35a989b76 > > [5/9] drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by > >https://git.kernel.org/kees/c/188aeb08bfaa > > [6/9] drm/vc4: Annotate struct vc4_perfmon with __counted_by > >https://git.kernel.org/kees/c/59a54dc896c3 > > [7/9] drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by > >https://git.kernel.org/kees/c/5cd476de33af > > [8/9] drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by > >https://git.kernel.org/kees/c/b426f2e5356a > > [9/9] drm/v3d: Annotate struct v3d_perfmon with __counted_by > >https://git.kernel.org/kees/c/dc662fa1b0e4 > > > > Take care, > > > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm: Annotate structs with __counted_by
On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote: > On Mon, Oct 2, 2023 at 5:20 AM Christian König > wrote: > > > > Am 29.09.23 um 21:33 schrieb Kees Cook: > > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: > > >> This is a batch of patches touching drm for preparing for the coming > > >> implementation by GCC and Clang of the __counted_by attribute. Flexible > > >> array members annotated with __counted_by can have their accesses > > >> bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array > > >> indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). > > >> > > >> As found with Coccinelle[1], add __counted_by to structs that would > > >> benefit from the annotation. > > >> > > >> [...] > > > Since this got Acks, I figure I should carry it in my tree. Let me know > > > if this should go via drm instead. > > > > > > Applied to for-next/hardening, thanks! > > > > > > [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with > > > __counted_by > > >https://git.kernel.org/kees/c/a6046ac659d6 > > > > STOP! In a follow up discussion Alex and I figured out that this won't work. I'm so confused; from the discussion I saw that Alex said both instances were false positives? > > > > The value in the structure is byte swapped based on some firmware > > endianness which not necessary matches the CPU endianness. > > SMU10 is APU only so the endianess of the SMU firmware and the CPU > will always match. Which I think is what is being said here? > > Please revert that one from going upstream if it's already on it's way. > > > > And because of those reasons I strongly think that patches like this > > should go through the DRM tree :) Sure, that's fine -- please let me know. It was others Acked/etc. Who should carry these patches? Thanks! -Kees > > > > Regards, > > Christian. > > > > > [2/9] drm/amdgpu/discovery: Annotate struct ip_hw_instance with > > > __counted_by > > >https://git.kernel.org/kees/c/4df33089b46f > > > [3/9] drm/i915/selftests: Annotate struct perf_series with __counted_by > > >https://git.kernel.org/kees/c/ffd3f823bdf6 > > > [4/9] drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by > > >https://git.kernel.org/kees/c/2de35a989b76 > > > [5/9] drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by > > >https://git.kernel.org/kees/c/188aeb08bfaa > > > [6/9] drm/vc4: Annotate struct vc4_perfmon with __counted_by > > >https://git.kernel.org/kees/c/59a54dc896c3 > > > [7/9] drm/virtio: Annotate struct virtio_gpu_object_array with > > > __counted_by > > >https://git.kernel.org/kees/c/5cd476de33af > > > [8/9] drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by > > >https://git.kernel.org/kees/c/b426f2e5356a > > > [9/9] drm/v3d: Annotate struct v3d_perfmon with __counted_by > > >https://git.kernel.org/kees/c/dc662fa1b0e4 > > > > > > Take care, > > > > > -- Kees Cook ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm: Annotate structs with __counted_by
Am 02.10.23 um 18:53 schrieb Kees Cook: On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote: On Mon, Oct 2, 2023 at 5:20 AM Christian König wrote: Am 29.09.23 um 21:33 schrieb Kees Cook: On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: This is a batch of patches touching drm for preparing for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by to structs that would benefit from the annotation. [...] Since this got Acks, I figure I should carry it in my tree. Let me know if this should go via drm instead. Applied to for-next/hardening, thanks! [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by https://git.kernel.org/kees/c/a6046ac659d6 STOP! In a follow up discussion Alex and I figured out that this won't work. I'm so confused; from the discussion I saw that Alex said both instances were false positives? The value in the structure is byte swapped based on some firmware endianness which not necessary matches the CPU endianness. SMU10 is APU only so the endianess of the SMU firmware and the CPU will always match. Which I think is what is being said here? Please revert that one from going upstream if it's already on it's way. And because of those reasons I strongly think that patches like this should go through the DRM tree :) Sure, that's fine -- please let me know. It was others Acked/etc. Who should carry these patches? Probably best if the relevant maintainer pick them up individually. Some of those structures are filled in by firmware/hardware and only the maintainers can judge if that value actually matches what the compiler needs. We have cases where individual bits are used as flags or when the size is byte swapped etc... Even Alex and I didn't immediately say how and where that field is actually used and had to dig that up. That's where the confusion came from. Regards, Christian. Thanks! -Kees Regards, Christian. [2/9] drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by https://git.kernel.org/kees/c/4df33089b46f [3/9] drm/i915/selftests: Annotate struct perf_series with __counted_by https://git.kernel.org/kees/c/ffd3f823bdf6 [4/9] drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by https://git.kernel.org/kees/c/2de35a989b76 [5/9] drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by https://git.kernel.org/kees/c/188aeb08bfaa [6/9] drm/vc4: Annotate struct vc4_perfmon with __counted_by https://git.kernel.org/kees/c/59a54dc896c3 [7/9] drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by https://git.kernel.org/kees/c/5cd476de33af [8/9] drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by https://git.kernel.org/kees/c/b426f2e5356a [9/9] drm/v3d: Annotate struct v3d_perfmon with __counted_by https://git.kernel.org/kees/c/dc662fa1b0e4 Take care, ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH vfio 03/11] virtio-pci: Introduce admin virtqueue
On 2023-09-27 p.m.5:27, Michael S. Tsirkin wrote:
If an existing device exposes a small
capability matching old size, then you change size then
the check will fail on the existing device and driver won't load.
All this happens way before feature bit checks.
Will do
Thanks
Feng
struct virtio_pci_modern_device {
--
2.27.0
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm: Annotate structs with __counted_by
On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote: > Am 02.10.23 um 18:53 schrieb Kees Cook: > > On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote: > > > On Mon, Oct 2, 2023 at 5:20 AM Christian König > > > wrote: > > > > Am 29.09.23 um 21:33 schrieb Kees Cook: > > > > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: > > > > > > This is a batch of patches touching drm for preparing for the coming > > > > > > implementation by GCC and Clang of the __counted_by attribute. > > > > > > Flexible > > > > > > array members annotated with __counted_by can have their accesses > > > > > > bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for > > > > > > array > > > > > > indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > > > > > > functions). > > > > > > > > > > > > As found with Coccinelle[1], add __counted_by to structs that would > > > > > > benefit from the annotation. > > > > > > > > > > > > [...] > > > > > Since this got Acks, I figure I should carry it in my tree. Let me > > > > > know > > > > > if this should go via drm instead. > > > > > > > > > > Applied to for-next/hardening, thanks! > > > > > > > > > > [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with > > > > > __counted_by > > > > > https://git.kernel.org/kees/c/a6046ac659d6 > > > > STOP! In a follow up discussion Alex and I figured out that this won't > > > > work. > > I'm so confused; from the discussion I saw that Alex said both instances > > were false positives? > > > > > > The value in the structure is byte swapped based on some firmware > > > > endianness which not necessary matches the CPU endianness. > > > SMU10 is APU only so the endianess of the SMU firmware and the CPU > > > will always match. > > Which I think is what is being said here? > > > > > > Please revert that one from going upstream if it's already on it's way. > > > > > > > > And because of those reasons I strongly think that patches like this > > > > should go through the DRM tree :) > > Sure, that's fine -- please let me know. It was others Acked/etc. Who > > should carry these patches? > > Probably best if the relevant maintainer pick them up individually. > > Some of those structures are filled in by firmware/hardware and only the > maintainers can judge if that value actually matches what the compiler > needs. > > We have cases where individual bits are used as flags or when the size is > byte swapped etc... > > Even Alex and I didn't immediately say how and where that field is actually > used and had to dig that up. That's where the confusion came from. Okay, I've dropped them all from my tree. Several had Acks/Reviews, so hopefully those can get picked up for the DRM tree? Thanks! -Kees -- Kees Cook ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm: Annotate structs with __counted_by
Am 02.10.23 um 20:08 schrieb Kees Cook: On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote: Am 02.10.23 um 18:53 schrieb Kees Cook: On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote: On Mon, Oct 2, 2023 at 5:20 AM Christian König wrote: Am 29.09.23 um 21:33 schrieb Kees Cook: On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: This is a batch of patches touching drm for preparing for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by to structs that would benefit from the annotation. [...] Since this got Acks, I figure I should carry it in my tree. Let me know if this should go via drm instead. Applied to for-next/hardening, thanks! [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by https://git.kernel.org/kees/c/a6046ac659d6 STOP! In a follow up discussion Alex and I figured out that this won't work. I'm so confused; from the discussion I saw that Alex said both instances were false positives? The value in the structure is byte swapped based on some firmware endianness which not necessary matches the CPU endianness. SMU10 is APU only so the endianess of the SMU firmware and the CPU will always match. Which I think is what is being said here? Please revert that one from going upstream if it's already on it's way. And because of those reasons I strongly think that patches like this should go through the DRM tree :) Sure, that's fine -- please let me know. It was others Acked/etc. Who should carry these patches? Probably best if the relevant maintainer pick them up individually. Some of those structures are filled in by firmware/hardware and only the maintainers can judge if that value actually matches what the compiler needs. We have cases where individual bits are used as flags or when the size is byte swapped etc... Even Alex and I didn't immediately say how and where that field is actually used and had to dig that up. That's where the confusion came from. Okay, I've dropped them all from my tree. Several had Acks/Reviews, so hopefully those can get picked up for the DRM tree? I will pick those up to go through drm-misc-next. Going to ping maintainers once more when I'm not sure if stuff is correct or not. Christian. Thanks! -Kees ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] drm: Annotate structs with __counted_by
On Mon, Oct 02, 2023 at 08:11:41PM +0200, Christian König wrote: > Am 02.10.23 um 20:08 schrieb Kees Cook: > > On Mon, Oct 02, 2023 at 08:01:57PM +0200, Christian König wrote: > > > Am 02.10.23 um 18:53 schrieb Kees Cook: > > > > On Mon, Oct 02, 2023 at 11:06:19AM -0400, Alex Deucher wrote: > > > > > On Mon, Oct 2, 2023 at 5:20 AM Christian König > > > > > wrote: > > > > > > Am 29.09.23 um 21:33 schrieb Kees Cook: > > > > > > > On Fri, 22 Sep 2023 10:32:05 -0700, Kees Cook wrote: > > > > > > > > This is a batch of patches touching drm for preparing for the > > > > > > > > coming > > > > > > > > implementation by GCC and Clang of the __counted_by attribute. > > > > > > > > Flexible > > > > > > > > array members annotated with __counted_by can have their > > > > > > > > accesses > > > > > > > > bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS > > > > > > > > (for array > > > > > > > > indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family > > > > > > > > functions). > > > > > > > > > > > > > > > > As found with Coccinelle[1], add __counted_by to structs that > > > > > > > > would > > > > > > > > benefit from the annotation. > > > > > > > > > > > > > > > > [...] > > > > > > > Since this got Acks, I figure I should carry it in my tree. Let > > > > > > > me know > > > > > > > if this should go via drm instead. > > > > > > > > > > > > > > Applied to for-next/hardening, thanks! > > > > > > > > > > > > > > [1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table > > > > > > > with __counted_by > > > > > > > https://git.kernel.org/kees/c/a6046ac659d6 > > > > > > STOP! In a follow up discussion Alex and I figured out that this > > > > > > won't work. > > > > I'm so confused; from the discussion I saw that Alex said both instances > > > > were false positives? > > > > > > > > > > The value in the structure is byte swapped based on some firmware > > > > > > endianness which not necessary matches the CPU endianness. > > > > > SMU10 is APU only so the endianess of the SMU firmware and the CPU > > > > > will always match. > > > > Which I think is what is being said here? > > > > > > > > > > Please revert that one from going upstream if it's already on it's > > > > > > way. > > > > > > > > > > > > And because of those reasons I strongly think that patches like this > > > > > > should go through the DRM tree :) > > > > Sure, that's fine -- please let me know. It was others Acked/etc. Who > > > > should carry these patches? > > > Probably best if the relevant maintainer pick them up individually. > > > > > > Some of those structures are filled in by firmware/hardware and only the > > > maintainers can judge if that value actually matches what the compiler > > > needs. > > > > > > We have cases where individual bits are used as flags or when the size is > > > byte swapped etc... > > > > > > Even Alex and I didn't immediately say how and where that field is > > > actually > > > used and had to dig that up. That's where the confusion came from. > > Okay, I've dropped them all from my tree. Several had Acks/Reviews, so > > hopefully those can get picked up for the DRM tree? > > I will pick those up to go through drm-misc-next. > > Going to ping maintainers once more when I'm not sure if stuff is correct or > not. Sounds great; thanks! -Kees -- Kees Cook ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] vhost-scsi: Spelling s/preceeding/preceding/g
On Thu, Sep 28, 2023 at 02:18:33PM +0200, Geert Uytterhoeven wrote: > Fix a misspelling of "preceding". > > Signed-off-by: Geert Uytterhoeven > --- > drivers/vhost/scsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2] virtio_balloon: Fix endless deflation and inflation on arm64
On Mon, Oct 02, 2023 at 01:50:45PM +0200, David Hildenbrand wrote:
> On 25.09.23 01:58, Gavin Shan wrote:
> > Hi David and Michael,
> >
> > On 8/31/23 11:10, Gavin Shan wrote:
> > > The deflation request to the target, which isn't unaligned to the
> > > guest page size causes endless deflation and inflation actions. For
> > > example, we receive the flooding QMP events for the changes on memory
> > > balloon's size after a deflation request to the unaligned target is
> > > sent for the ARM64 guest, where we have 64KB base page size.
> > >
> > > /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \
> > > -accel kvm -machine virt,gic-version=host -cpu host \
> > > -smp maxcpus=8,cpus=8,sockets=2,clusters=2,cores=2,threads=1 \
> > > -m 1024M,slots=16,maxmem=64G \
> > > -object memory-backend-ram,id=mem0,size=512M \
> > > -object memory-backend-ram,id=mem1,size=512M \
> > > -numa node,nodeid=0,memdev=mem0,cpus=0-3 \
> > > -numa node,nodeid=1,memdev=mem1,cpus=4-7 \
> > > : \
> > > -device virtio-balloon-pci,id=balloon0,bus=pcie.10
> > >
> > > { "execute" : "balloon", "arguments": { "value" : 1073672192 } }
> > > {"return": {}}
> > > {"timestamp": {"seconds": 1693272173, "microseconds": 88667}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272174, "microseconds": 89704}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272175, "microseconds": 90819}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272176, "microseconds": 91961}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272177, "microseconds": 93040}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
> > > {"timestamp": {"seconds": 1693272178, "microseconds": 94117}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
> > > {"timestamp": {"seconds": 1693272179, "microseconds": 95337}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272180, "microseconds": 96615}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
> > > {"timestamp": {"seconds": 1693272181, "microseconds": 97626}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272182, "microseconds": 98693}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
> > > {"timestamp": {"seconds": 1693272183, "microseconds": 99698}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272184, "microseconds": 100727}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272185, "microseconds": 90430}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > {"timestamp": {"seconds": 1693272186, "microseconds": 102999}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073676288}}
> > >:
> > >
> > >
> > > Fix it by aligning the target up to the guest page size, 64KB in this
> > > specific case. With this applied, no flooding QMP events are observed
> > > and the memory balloon's size can be stablizied to 0x3ffe soon
> > > after the deflation request is sent.
> > >
> > > { "execute" : "balloon", "arguments": { "value" : 1073672192 } }
> > > {"return": {}}
> > > {"timestamp": {"seconds": 1693273328, "microseconds": 793075}, \
> > > "event": "BALLOON_CHANGE", "data": {"actual": 1073610752}}
> > > { "execute" : "query-balloon" }
> > > {"return": {"actual": 1073610752}}
> > >
> > > Signed-off-by: Gavin Shan
> > > Tested-by: Zhenyu Zhang
> > > ---
> > > v2: Align @num_pages up to the guest page size in towards_target()
> > > directly as David suggested.
> > > ---
> > >drivers/virtio/virtio_balloon.c | 6 +-
> > >1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> >
> > If the patch looks good, could you please merge this to Linux 6.6.rc4 since
> > it's something needed by our downstream. I hope it can land upstream as
> > early
> > as possible, thanks a lot.
>
> @MST, I cannot spot it in your usual vhost git yet. Should I pick it up or
> what are your plans?
Yes - I merged it but I'm still testing my tree. Will be in
the next pull request.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
