All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 2/4] x86/hvm: fix handling of accesses to partial r/o MMIO pages
Date: Thu, 17 Apr 2025 18:23:44 +0200	[thread overview]
Message-ID: <aAErECZ1Ys-Nufon@macbook.lan> (raw)
In-Reply-To: <f71bc0f8-8de1-4ecd-a2c0-a420e991e429@suse.com>

On Thu, Apr 17, 2025 at 05:38:54PM +0200, Jan Beulich wrote:
> On 17.04.2025 17:25, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/emulate.c
> > +++ b/xen/arch/x86/hvm/emulate.c
> > @@ -370,7 +370,15 @@ static int hvmemul_do_io(
> >          /* If there is no suitable backing DM, just ignore accesses */
> >          if ( !s )
> >          {
> > -            if ( is_mmio && is_hardware_domain(currd) )
> > +            if ( is_mmio && is_hardware_domain(currd) &&
> > +                 /*
> > +                  * Do not attempt to fixup write accesses to r/o MMIO regions,
> > +                  * they are expected to be terminated by the null handler
> > +                  * below.
> > +                  */
> > +                 (!rangeset_contains_singleton(mmio_ro_ranges,
> > +                                               PFN_DOWN(addr)) ||
> > +                  dir == IOREQ_READ) )
> 
> These two would better be swapped, for the cheap one to be done first.

Can swap, thanks for pointing out.

> > --- /dev/null
> > +++ b/xen/arch/x86/hvm/mmio.c
> > @@ -0,0 +1,125 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * MMIO related routines.
> > + *
> > + * Copyright (c) 2025 Cloud Software Group
> > + */
> > +
> > +#include <xen/io.h>
> > +#include <xen/mm.h>
> > +
> > +#include <asm/p2m.h>
> > +
> > +static int cf_check subpage_mmio_accept(struct vcpu *v, unsigned long addr)
> > +{
> > +    p2m_type_t t;
> > +    mfn_t mfn = get_gfn_query_unlocked(v->domain, PFN_DOWN(addr), &t);
> > +
> > +    return !mfn_eq(mfn, INVALID_MFN) && t == p2m_mmio_direct &&
> > +           subpage_mmio_find_page(mfn);
> > +}
> > +
> > +/*
> > + * The guest has read access to those regions, and consequently read accesses
> > + * shouldn't fault.  However read-modify-write operations may take this path,
> > + * so handling of reads is necessary.
> > + */
> > +static int cf_check subpage_mmio_read(
> > +    struct vcpu *v, unsigned long addr, unsigned int len, unsigned long *data)
> > +{
> > +    struct domain *d = v->domain;
> > +    unsigned long gfn = PFN_DOWN(addr);
> > +    p2m_type_t t;
> > +    mfn_t mfn;
> > +    struct subpage_ro_range *entry;
> > +    volatile void __iomem *mem;
> > +
> > +    *data = ~0UL;
> > +
> > +    if ( !IS_ALIGNED(len | addr, len) )
> 
> What's the point of doing the | ? len can't be misaligned with itself?

Hm, it's the same form that's used in mmio_ro_emulated_write(), I
assumed it was to catch illegal access lengths, like 3.

> > --- a/xen/arch/x86/include/asm/mm.h
> > +++ b/xen/arch/x86/include/asm/mm.h
> > @@ -554,6 +554,18 @@ int cf_check mmio_ro_emulated_write(
> >      enum x86_segment seg, unsigned long offset, void *p_data,
> >      unsigned int bytes, struct x86_emulate_ctxt *ctxt);
> >  
> > +/* r/o MMIO subpage access handlers. */
> > +struct subpage_ro_range {
> > +    struct list_head list;
> > +    mfn_t mfn;
> > +    void __iomem *mapped;
> > +    DECLARE_BITMAP(ro_elems, PAGE_SIZE / MMIO_RO_SUBPAGE_GRAN);
> > +};
> > +struct subpage_ro_range *subpage_mmio_find_page(mfn_t mfn);
> > +void __iomem *subpage_mmio_map_page(struct subpage_ro_range *entry);
> 
> I notice you didn't move the __iomem, which - as indicated - I agree with,
> but Andrew didn't. Did you sort this with him privately?

I will raise with him, seeing as he didn't reply to your last email, I
assumed he was OK with the reasoning?

Thanks, Roger.


  reply	other threads:[~2025-04-17 16:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 15:25 [PATCH v3 0/4] xen/x86: fix implementation of subpage r/o MMIO Roger Pau Monne
2025-04-17 15:25 ` [PATCH v3 1/4] xen/io: provide helpers for multi size MMIO accesses Roger Pau Monne
2025-04-17 15:32   ` Jan Beulich
2025-04-17 15:25 ` [PATCH v3 2/4] x86/hvm: fix handling of accesses to partial r/o MMIO pages Roger Pau Monne
2025-04-17 15:38   ` Jan Beulich
2025-04-17 16:23     ` Roger Pau Monné [this message]
2025-04-22  6:46       ` Jan Beulich
2025-04-23  8:21         ` Roger Pau Monné
2025-04-23  8:32           ` Jan Beulich
2025-04-23  8:52             ` Roger Pau Monné
2025-04-17 15:25 ` [PATCH v3 3/4] x86/hvm: only register the r/o subpage ops when needed Roger Pau Monne
2025-04-17 15:25 ` [PATCH v3 4/4] x86/mm: move mmio_ro_emulated_write() to PV only file Roger Pau Monne

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=aAErECZ1Ys-Nufon@macbook.lan \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.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.