linux-kernel - Re: [PATCH V3 1/2] xen: Update dm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3770f13f-0621-48af-4c79-880a0ffaa8a6@suse.com>
Date:   Tue, 25 Jul 2023 09:18:05 +0200
From:   Jan Beulich <jbeulich@...e.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Vincent Guittot <vincent.guittot@...aro.org>,
        Alex Bennée <alex.bennee@...aro.org>,
        stratos-dev@...lists.linaro.org,
        Erik Schilling <erik.schilling@...aro.org>,
        Manos Pitsidianakis <manos.pitsidianakis@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [PATCH V3 1/2] xen: Update dm_op.h from Xen public header

On 25.07.2023 09:09, Viresh Kumar wrote:
> On 25-07-23, 09:04, Jan Beulich wrote:
>> On 25.07.2023 08:47, Viresh Kumar wrote:
>>> +struct xen_dm_op {
>>> +    uint32_t op;
>>> +    uint32_t pad;
>>> +    union {
>>> +        struct xen_dm_op_create_ioreq_server create_ioreq_server;
>>> +        struct xen_dm_op_get_ioreq_server_info get_ioreq_server_info;
>>> +        struct xen_dm_op_ioreq_server_range map_io_range_to_ioreq_server;
>>> +        struct xen_dm_op_ioreq_server_range unmap_io_range_from_ioreq_server;
>>> +        struct xen_dm_op_set_ioreq_server_state set_ioreq_server_state;
>>> +        struct xen_dm_op_destroy_ioreq_server destroy_ioreq_server;
>>> +        struct xen_dm_op_track_dirty_vram track_dirty_vram;
>>> +        struct xen_dm_op_set_pci_intx_level set_pci_intx_level;
>>> +        struct xen_dm_op_set_isa_irq_level set_isa_irq_level;
>>> +        struct xen_dm_op_set_irq_level set_irq_level;
>>> +        struct xen_dm_op_set_pci_link_route set_pci_link_route;
>>> +        struct xen_dm_op_modified_memory modified_memory;
>>> +        struct xen_dm_op_set_mem_type set_mem_type;
>>> +        struct xen_dm_op_inject_event inject_event;
>>> +        struct xen_dm_op_inject_msi inject_msi;
>>> +        struct xen_dm_op_map_mem_type_to_ioreq_server map_mem_type_to_ioreq_server;
>>> +        struct xen_dm_op_remote_shutdown remote_shutdown;
>>> +        struct xen_dm_op_relocate_memory relocate_memory;
>>> +        struct xen_dm_op_pin_memory_cacheattr pin_memory_cacheattr;
>>> +        struct xen_dm_op_nr_vcpus nr_vcpus;
>>> +    } u;
>>> +};
>>
>> Is sync-ing for the sake of sync-ing really useful? For example, are any
>> of the ioreq server elements halfway likely to ever be used in the kernel?
> 
> The only field, out of the union, I am using for now is:
> 
>         struct xen_dm_op_set_irq_level set_irq_level;
> 
> I am not sure if some of the others are going to be used or not in the
> future.

I question that use, btw, but it is not up to me to decide whether to
accept such a layering violation in Linux. dm-op is, as its name says,
for device models to use. Your intended use doesn't fall in that
category, aiui. Imo the present contents of dm_op.h in Linux is indeed
all a kernel is supposed to know about, unless it was to gain in-kernel
device models.

Jan