All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control
Date: Fri, 5 Jun 2015 16:57:05 +0100	[thread overview]
Message-ID: <5571C6D1.1070009@citrix.com> (raw)
In-Reply-To: <5571A3F202000078000814CA@mail.emea.novell.com>

On 05/06/15 12:28, Jan Beulich wrote:
> Qemu shouldn't be fiddling with this bit directly, as the hypervisor
> may (and now does) use it for its own purposes. Provide it with a
> replacement interface, allowing the hypervisor to track host and guest
> masking intentions independently (clearing the bit only when both want
> it clear).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Whether the permission check should really be an XSM_TARGET one needs
> to be determined: That allowing the guest to issue the hypercalls on
> itself means permitting it to bypass the device model, and thus render
> device model state stale.

I concur.

On the other hand, there should be nothing the guest could do with
access to these hypercalls which would damage Xen itself.

>
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1807,6 +1807,17 @@ int xc_physdev_unmap_pirq(xc_interface *
>                            int domid,
>                            int pirq);
>  
> +int xc_physdev_msix_enable(xc_interface *xch,
> +                           int segment,
> +                           int bus,
> +                           int devfn,
> +                           int on);
> +int xc_physdev_msix_mask_all(xc_interface *xch,
> +                             int segment,
> +                             int bus,
> +                             int devfn,
> +                             int mask);
> +
>  int xc_hvm_set_pci_intx_level(
>      xc_interface *xch, domid_t dom,
>      uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
> --- a/tools/libxc/xc_physdev.c
> +++ b/tools/libxc/xc_physdev.c
> @@ -112,3 +112,38 @@ int xc_physdev_unmap_pirq(xc_interface *
>      return rc;
>  }
>  
> +int xc_physdev_msix_enable(xc_interface *xch,
> +                           int segment,
> +                           int bus,
> +                           int devfn,
> +                           int on)
> +{
> +    struct physdev_pci_device dev = {
> +        .seg = segment,
> +        .bus = bus,
> +        .devfn = devfn
> +    };
> +
> +    return do_physdev_op(xch,
> +                         on ? PHYSDEVOP_msix_enable
> +                            : PHYSDEVOP_msix_disable,
> +                         &dev, sizeof(dev));
> +}

xc_physdev_misx_enable(xch, X, Y, Z, 0) is slightly misleading to read...

> +
> +int xc_physdev_msix_mask_all(xc_interface *xch,
> +                             int segment,
> +                             int bus,
> +                             int devfn,
> +                             int mask)
> +{
> +    struct physdev_pci_device dev = {
> +        .seg = segment,
> +        .bus = bus,
> +        .devfn = devfn
> +    };
> +
> +    return do_physdev_op(xch,
> +                         mask ? PHYSDEVOP_msix_mask_all
> +                              : PHYSDEVOP_msix_unmask_all,
> +                         &dev, sizeof(dev));
> +}

And equally xc_physdev_misx_mask_all(xch, X, Y, Z, 0).

I think it would be cleaner to have something like

xc_physdev_msix_manage(xch, X, Y, Z, PHYSDEVOP_msix_XXX)

which results in far more readable client code.

Otherwise, the rest looks fine.

  reply	other threads:[~2015-06-05 15:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 11:09 [PATCH v3 00/10] x86/MSI-X: XSA-120, 128..131 follow-up Jan Beulich
2015-06-05 11:20 ` [PATCH v3 01/10] x86/MSI-X: be more careful during teardown Jan Beulich
2015-06-05 11:20 ` [PATCH v3 02/10] x86/MSI-X: access MSI-X table only after having enabled MSI-X Jan Beulich
2015-06-05 13:01   ` Andrew Cooper
2015-06-05 11:21 ` [PATCH v3 03/10] x86/MSI-X: reduce fiddling with control register during restore Jan Beulich
2015-06-05 11:21 ` [PATCH v3 04/10] x86/MSI-X: cleanup Jan Beulich
2015-06-05 11:22 ` [PATCH v3 05/10] x86/MSI: track host and guest masking separately Jan Beulich
2015-06-05 13:05   ` Andrew Cooper
2016-04-01  7:40   ` Li, Liang Z
2016-04-01  8:47     ` Jan Beulich
2016-04-01  9:21       ` Li, Liang Z
2016-04-01  9:33         ` Jan Beulich
2015-06-05 11:23 ` [PATCH v3 06/10] x86/vMSI-X: cleanup Jan Beulich
2015-06-05 13:07   ` Andrew Cooper
2015-06-05 11:24 ` [PATCH v3 07/10] x86/vMSI-X: support qword MMIO access Jan Beulich
2015-06-05 15:34   ` Andrew Cooper
2015-06-05 11:25 ` [PATCH v3 08/10] x86/MSI-X: use qword MMIO access for address writes Jan Beulich
2015-06-05 15:37   ` Andrew Cooper
2015-06-05 11:26 ` [PATCH v3 09/10] VT-d: use qword MMIO access for MSI " Jan Beulich
2015-06-05 15:39   ` Andrew Cooper
2015-06-05 15:46     ` Jan Beulich
2015-06-11  7:45   ` Tian, Kevin
2015-06-05 11:28 ` [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control Jan Beulich
2015-06-05 15:57   ` Andrew Cooper [this message]
2015-06-05 16:17     ` Jan Beulich
2015-06-11  8:35   ` Jan Beulich
2015-06-11  9:51     ` Andrew Cooper
2015-06-19 13:00       ` Jan Beulich
2015-06-19 13:05         ` Konrad Rzeszutek Wilk
2015-06-19 14:52           ` Jan Beulich
2015-06-19 14:07         ` Roger Pau Monné
2015-06-19 14:58           ` Jan Beulich
2015-06-22 17:02             ` Roger Pau Monné
2015-06-23  7:20               ` Jan Beulich
2015-06-23  7:29                 ` Roger Pau Monné
2015-06-23  8:13                   ` Jan Beulich
2015-06-22 11:25           ` Jan Beulich
2015-06-12 13:21     ` Konrad Rzeszutek Wilk
2015-06-12 13:51       ` Jan Beulich
2015-06-12 14:17         ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5571C6D1.1070009@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.