[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/3] x86/msi: passthrough all MSI-X vector ctrl writes to device model
- To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 27 Mar 2023 12:12:29 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jo5dWKE2xHXN07tXbu3fqBhFzZpbMO/vJwx1vsjB3ks=; b=cFdUMzmmzxmciJd40iFzvw1/IwkN6s1hj1tBXdxENcSSW4+1dtoFjl+gWLRKFxDZfLvBSD7dLT68Kx3BcM5pygWV/VJynmAjHe6EnS2+hPzGRMYTX/dii6O8ST1EQ35xDf7xPtDn9KRzqw2Ju8BK9aRMbcqD6QXFuvtHljcfevwbqwrFpeU4fdJA7tPKtvZmJ58wkOL3PO33ZgNnIKWdZWVLhAb1Fu7FvZ2Y1aIJxbZFup2ju4a1JZVv0gdFQBjcayg2buBmakK9SUpZwnkpMRIdQ0TNcn1y+/IZ20VMi8d0Am6j0UdQVPdFth0VQJ05y7EBuKecFrrA2nX/DXAVMA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nCzqVzXFCapvSgsqnMLhIdPyKXt+OHh7A2rFzwEzxGLLCe7nQ2XMsrg/gO0N2W2HIR33qcX4aQug5eZENUNK6PorQ1qb0E9XNIe/p4nTuTxeckUj0QDo6JfIpZrHy9VjXKDpei3kPbb5lvd/gTSqKKWQYZSY67oowqm7yGbVK6KxqwP9SnljB0EVKshmbMbhP1JC0npqv01W4ISEo9pLarhbD1auV89/rYd19RooYfsFnfO2LInpfAVrxlWje3l9F2zb8MPgIlZM1hrMg3kkVyIIo6a3p1qJ5YPNPgr1fK5NrJmrrI4FJDH3dmZJ3NtwKYx6+J0oA8G0p/F+sjbsqQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Jason Andryuk <jandryuk@xxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Mon, 27 Mar 2023 10:12:55 +0000
- Ironport-data: A9a23:8FH506i5GEfryhI9HrL4wpt7X161vREKZh0ujC45NGQN5FlHY01je htvXmCFMv2NMGajeY9wbtywpxsAusDUx9IwQAU/rio9RSkb9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmYpHlUMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWi0N8klgZmP6sT5wWBzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQiMTAMcw/EutuNxavmZ7JRpZ4CEJXCadZ3VnFIlVk1DN4AaLWaG+Dv2oUd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEsluG1abI5efTTLSlRtlyfq W/cuXzwHzkRNcCFyCrD+XWp7gPKtXqjA9lORebmp5aGhnW47DYuSy8IW2C2sOKr03K4ePF9E WYbr39GQa8asRbDosPGdxixunuNpBMfc9tWDewh6QuJx7bU4gCWHWwNRHhKb9lOnN87Q3km2 0GEm/vtBCdzq/uFRHSF7LCWoDiufy8PIgcqZyYCQREU/trLr4Q6jxaJRdFmeIa3hNDoHTD7w xiRsTMzwb4UiKYjyKGT7V3BxTW2qfD0ohUd4wzWWieg8Vl/bYv8P4iwswGDtLBHMZqTSUSHs D4cgc+C4esSDJaL0iuQXOEKG7Lv7PGAWNHBvWNS81Aa32zF0xaekUp4uVmS+G8B3h44RALU
- Ironport-hdrordr: A9a23:JbacT6O7i48/6MBcTj+jsMiBIKoaSvp037Dk7TEKdfUzSL3rqy nOpoVp6faaskdvZJhNo6H8BEDEewKtyXcX2/hhAV7BZnibhILAFugLnOiSoUyEakmOkZ866U 4jSdkENDSaNykCsS+V2njBLz9t+qj4zEgn7d20859/JjsBV0ljhD0VNu/NKCFLrFEtP/UE/J 323KR6TzzKQxUqhsDRPBk4dtmGmfXWmZL6QTNuPW9T1DWz
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Sat, Mar 25, 2023 at 03:49:22AM +0100, Marek Marczykowski-Górecki wrote:
> QEMU needs to know whether clearing maskbit of a vector is really
> clearing, or was already cleared before. Currently Xen sends only
> clearing that bit to the device model, but not setting it, so QEMU
> cannot detect it. Because of that, QEMU is working this around by
> checking via /dev/mem, but that isn't the proper approach.
>
> Give all necessary information to QEMU by passing all ctrl writes,
> including masking a vector. This does include forwarding also writes
> that did not change the value, but as tested on both Linux (6.1.12) and
> Windows (10 pro), they don't do excessive writes of unchanged values
> (Windows seems to clear maskbit in some cases twice, but not more).
Since we passthrough all the accesses to the device model, is the
handling in Xen still required? It might be worth to also expose any
interfaces needed to the device model so all the functionality done by
the msixtbl_mmio_ops hooks could be done by QEMU, since we end up
passing the accesses anyway.
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> ---
> v2:
> - passthrough quad writes to emulator too (Jan)
> - (ab)use len==0 for write len=4 completion (Jan), but add descriptive
> #define for this magic value
>
> This behavior change needs to be surfaced to the device model somehow,
> so it knows whether it can rely on it. I'm open for suggestions.
Maybe exposed in XEN_DMOP_get_ioreq_server_info?
But I wonder whether it shouldn't be the other way arround, the device
model tells Xen it doesn't need to handle any MSI-X accesses because
QEMU will take care of it, likely using a new flag in
XEN_DMOP_create_ioreq_server or maybe in XEN_DOMCTL_bind_pt_irq as
part of the gflags, but then we would need to assert that the flag is
passed for all MSI-X interrupts bound from that device to the same
domain.
Thanks, Roger.
|
