[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 5/6] xen/x86: add PHYSDEVOP_msi_msix_set_enable


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • Date: Fri, 1 Feb 2019 16:58:28 -0500
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 01 Feb 2019 21:59:02 +0000
  • Ironport-phdr: 9a23:ohmU5xGcHNbcGT8hWstSBJ1GYnF86YWxBRYc798ds5kLTJ76osizbnLW6fgltlLVR4KTs6sC17KG9fi4EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCa+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhzsGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7Sc8kaRW5cVchPUSJPDJ63Y48WA+YfIepUqo/wrEYMoxSjHwmhHP7hxCFGhnH23qM03eouHg7E0wM8ENwDq2jUodbvOasOTey4wqvFwDPeZP1Wwzf9743Ifwgvr/6WW7JwcNTeyU0yHA3LkFqbtI3rPymP2esXvWiQ8u1tWv+gi2E6tQ5xrSKvyd03h4nVhoMa1lDE9SJjzIYzPt23UlR3YdGjEJtOriyXMZZ9TMA6Q2xwpSo3xbILtYS7cSQX0pgr2RHSZ+Kdf4SV5B/oSfyfLi1ihH1/fbKynxOy8U+9xeLiTsS0y1NKrjZdktnLq3ANywTf6siZRft5+UeswSqP2BrJ6uFFPEA0jrDXK4Ihw7EslpoTtl7PHinql0XtkKCabEAk+ums6+j/Y7XmoIGTN5Nshw3jPakjldazDOQlPgQUQWSW9vqw2Kf+8UHhRbVFlPw2kq3XsJDAIsQbo7a0DBJa0ok+9Rm/AC2m384DkHkbLFNKZBKHj4/zN1HIO/D3F+2zg1urkDd13/zGJKHuAo3RLnjfl7fsZax960lTyAUt19BT/YpUBascIP/oRkDxtcDYDgU4Mw272eroFNJ91oYGU2KVHqCZKL/SsUOP5u83JumDfpUVuDPnJPg/+fHujmQ0mV4bfam33JsXc3G4Ee9iI0qHfXrsgtYBEWEFvgolSOzlkkaNXSRPaHa1WqI2/is7B56+DYffWoCth6SM3SilEZ1Qf2xJF06DEWn2eIWAQPoMbCOSItR9kjwfT7SgRJEu1Re2tA/gzLpnLPTb9TEEtZ7509h1/eLTnwko9TNoF8Sdz32NT2Zsk2MKXDA5wr1/oUh8ylif0ah1mOdYFcFI5/xXSAs1KZncz+liAdDoRg3BZsuJSEqhQti+Gz4xSM8+w8UQbEdzAdmtkhfD3y2yA7ALjbyGCoc5/b7d33jtPcZ9ynnH2LM9gFkhR8tFLXemibJn9wjPG47JlF2Ulqi0eqQdxiLN8GaDzXeQsExDTAFwULnFXWoeZkrZt9j2+kTCT7q2A7Q9LgRB0dKCKrdNatDxjFtJWvDjOM7RY22vgWu+CwuIxrWIbIXwY2UQxzvSCFUenw8P/HaGKRI+Biauom7EEDNuElfvaVv28eZisHO7UlM0zwaSYk1gzbW1/AQZhf6GRPwP3bIEoyAhqzNvEVmjwtLaEcaPpwt9fKVGYNM8701L2n7etwx4JpagNbxthkYCcwRruEPjzxd3CphEkcgrsnwqyhB+Ka2C0FxbczOY2Yv9NafNKmn35hygd6nW2lTG2taM5qgP8Og4q0nkvAyxFUoi9HNn08NP3HSB/JnLAgsSUZbyUkss8Bh6vavVbTU554zKz3FjLa60sjra0dIzGOQl0gqgf8tYMK6cDw/yCNEaCNK1J+M0n1ipahMEPOZT9KMvPMOpaeGG2Ki1M+Zkhj6min5H4I9l2EKW6yV8UvLI34oCw/yAwguHVjL8gUyus8/pn4BIfzYSHnCwyXusOIkEXKp9cJw8MW6zFOiwwNP/z8r3XHFV7hi7Dk4u0861YxuCKVf62FsUnWEeu3Gkrg6x1TdmgjIusbGc3WnhWP7vfxkGcjpOTXNnhE3hIqC1ic4bR0miawU1lBqj6l3+zqIdr6N6eTr9W0BNKgT/KWBvVuOcu/KtecdG5tt8vSpbXeumaHiGW7X9pF0cyCqlEGxAkmNoPwq2s4n0ykQpwFmWK2x++T+AI5l9
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 1/30/19 8:51 AM, Roger Pau Monné wrote:
On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:
Allow device model running in stubdomain to enable/disable MSI(-X),
bypassing pciback. While pciback is still used to access config space
from within stubdomain, it refuse to write to
PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
is the right thing to do for PV domain (the main use case for pciback),
as PV domain should use XEN_PCI_OP_* commands for that. Unfortunately
those commands are not good for stubdomain use, as they configure MSI in
dom0's kernel too, which should not happen for HVM domain.

This new physdevop is allowed only for stubdomain controlling the domain
which own the device.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>

Thanks!

---
Changes in v3:
  - new patch

This is rather RFC. Any suggestions for shorter name? Also, I'm not sure
if physdev_msi_msix_set_enable.flag is the best name/idea.

I've made some comments below.

Should it be plugged into XSM? Any suggestions how exactly? New
function with XSM_DM_PRIV default action? Should it get target domain
only, or also machine_bdf?

You should Cc the XSM maintainer I think, which I've done now.

Yes, I think you need to pass both the domain and machine_bdf; the hook
sounds like it should be similar to the existing map_domain_irq or
assign_device hooks: check that the device model has rights to do this
operation on the device, and also check that the device model has rights
to modify devices assigned to the device's owner (this check is why the
domain is needed).

Alternatively, you can hard-code the requirement to be the target domain,
but I think this prevents using the same hooks from a dom0 device model.
If that's already the case, this is less of an issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.