qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Yi Sun <yi.y.sun@linux.intel.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net,
	ehabkost@redhat.com, mst@redhat.com, marcel.apfelbaum@gmail.com,
	kevin.tian@intel.com, yi.l.liu@intel.com, yi.y.sun@intel.com
Subject: Re: [Qemu-devel] [RFC v1 1/3] intel_iommu: scalable mode emulation
Date: Wed, 13 Feb 2019 16:03:05 +0800	[thread overview]
Message-ID: <20190213080305.GA6228@xz-x1> (raw)
In-Reply-To: <20190213073855.GE16968@yi.y.sun>

On Wed, Feb 13, 2019 at 03:38:55PM +0800, Yi Sun wrote:

[...]

> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index 8b72735..396ac8e 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -37,6 +37,34 @@
> > >  #include "kvm_i386.h"
> > >  #include "trace.h"
> > >  
> > > +#define vtd_devfn_check(devfn) ((devfn & VTD_DEVFN_CHECK_MASK) ? true : false)
> > 
> > "vtd_devfn_check(devfn)" is merely as long as "devfn &
> > VTD_DEVFN_CHECK_MASK", isn't it? :)
> > 
> > I would just drop the macro.
> > 
> There are two places to call this macro. Is that valuable to keep it?

The point here is "A ? true : false" is exactly "A" when used in
condition checks.  So IMHO it's clean enough to write:

  if (devfn & VTD_DEVFN_CHECK_MASK) {
    ...
  }

Comparing to:

  if (vtd_devfn_check(devfn)) {
    ...
  }

And imho actually the name "check"/"mask" is confusing itself
already...  So maybe even dropping both vtd_devfn_check() and
VTD_DEVFN_CHECK_MASK (note: there's nothing about any validity checks,
and it's not a mask at all!) and simply:

  if (devfn >= UINT8_MAX / 2)

That's even clearer to me that it's splitted into two halves.

[...]

> > > diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
> > > index a321cc9..ff13ff27 100644
> > > --- a/include/hw/i386/intel_iommu.h
> > > +++ b/include/hw/i386/intel_iommu.h
> > > @@ -66,11 +66,12 @@ typedef struct VTDIOTLBEntry VTDIOTLBEntry;
> > >  typedef struct VTDBus VTDBus;
> > >  typedef union VTD_IR_TableEntry VTD_IR_TableEntry;
> > >  typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress;
> > > +typedef struct VTDPASIDDirEntry VTDPASIDDirEntry;
> > > +typedef struct VTDPASIDEntry VTDPASIDEntry;
> > >  
> > >  /* Context-Entry */
> > >  struct VTDContextEntry {
> > > -    uint64_t lo;
> > > -    uint64_t hi;
> > > +    uint64_t val[4];
> > 
> > You can actually make it an enum, two benefits:
> > 
> Thanks for the suggestion! DYM 'union'?

Yes. :)

Regards,

-- 
Peter Xu

  reply	other threads:[~2019-02-13  8:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30  5:09 [Qemu-devel] [RFC v1 0/3] intel_iommu: support scalable mode Yi Sun
2019-01-30  5:09 ` [Qemu-devel] [RFC v1 1/3] intel_iommu: scalable mode emulation Yi Sun
2019-02-11 10:12   ` Peter Xu
2019-02-13  7:38     ` Yi Sun
2019-02-13  8:03       ` Peter Xu [this message]
2019-02-13  8:28         ` Peter Xu
2019-01-30  5:09 ` [Qemu-devel] [RFC v1 2/3] intel_iommu: add 256 bits qi_desc support Yi Sun
2019-02-12  6:27   ` Peter Xu
2019-02-13  9:00     ` Yi Sun
2019-02-13 10:42       ` Peter Xu
2019-02-14  1:52         ` Yi Sun
2019-02-14  3:24           ` Peter Xu
2019-02-14  6:27             ` Yi Sun
2019-02-14  7:13               ` Peter Xu
2019-02-14  7:35                 ` Tian, Kevin
2019-02-14  8:13                   ` Peter Xu
2019-02-14  8:22                     ` Tian, Kevin
2019-02-14  8:43                       ` Peter Xu
2019-01-30  5:09 ` [Qemu-devel] [RFC v1 3/3] intel_iommu: add scalable-mode option to make scalable mode work Yi Sun
2019-02-12  6:46   ` Peter Xu
2019-02-15  5:22     ` Yi Sun
2019-02-15  5:39       ` Peter Xu
2019-02-15  7:44         ` Yi Sun
2019-02-15  8:22         ` Jason Wang
2019-02-11 10:37 ` [Qemu-devel] [RFC v1 0/3] intel_iommu: support scalable mode Peter Xu
2019-02-13  5:46   ` Yi Sun

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=20190213080305.GA6228@xz-x1 \
    --to=peterx@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@intel.com \
    --cc=yi.y.sun@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).