Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, mst@redhat.com,
	agordeev@redhat.com
Subject: Re: [kvm-unit-tests PATCH v2 01/10] asm-generic: add portio accessors to io.h
Date: Mon, 18 Jan 2016 18:02:16 +0100	[thread overview]
Message-ID: <20160118170216.GJ4075@hawk.localdomain> (raw)
In-Reply-To: <20160118164003.GB14830@potion.brq.redhat.com>

On Mon, Jan 18, 2016 at 05:40:04PM +0100, Radim Krčmář wrote:
> 2016-01-18 14:52+0100, Andrew Jones:
> > On Fri, Jan 15, 2016 at 10:34:09PM +0100, Radim Krčmář wrote:
> >> 2016-01-15 17:51+0100, Andrew Jones:
> >> My first reaction was "throw this abomination out!", but Drew explained
> >> that in*/out* is here because we'll also generalize the x86 PCI code
> >> (which uses PIO and MMIO) and that Linux has the same code.
> >> 
> >> arm, arm64, and unicore32 define PCI_IOBASE in Linux.  I didn't figure
> >> out why they want to use a PIO based abstraction for MMIO, so the
> >> interface is fine with me as long as
> > 
> > Having these aliases for read*/write* are less evil than attempting to
> > share code between arm and x86 with a bunch of #ifdefs.
> 
> #ifs in plain sight are definitely evil, but we could have wrapped
> read*/write*/in*/out* in an interface that doesn't violate most basic
> types and is hidden with at most one #ifdef.
> 
> >                                                         As I didn't yet
> > write a shared pci-testdev driver though, then this patch can be dropped
> > for now, if you'd prefer. However at some point it may need to come back.
> 
> I'd continue doing what ioread*() in x86/vmexit.c does.
> Using a loosely-tagged union also means that we don't need to implement
> in*/out* for everyone.
> 
> And because structs are a pain to use, having two separate values
> instead of
>   struct {
>    enum {PIO, MMIO} space;
>    union {u16 port; void * address;};};
> 
> can be excused.
> 
> >>  - functions are hidden behind a single #ifndef, like ARCH_HAS_PORT_IO.
> >>    (Ideally defined as part of global configuration, because it's harder
> >>     to fail that way.)
> > 
> > I prefer to stay consistent with Linux. It's ugly, but we already have
> > the ugliness for read* and write*.
> 
> Good point, copy-pasting code is convenient and we don't plan to outlive
> Linux anyway ...
> 
> I'd rather drop this patch now and wait for the first use, but it has my
> 
> Reviewed-by: Radim Krčmář <rkrcmar@redhat.com>

Thanks, but I'll just drop this patch for now. We'll see how Alex
implements the common pci-testdev. If he needs this stuff to allow it to more
easily be shared with x86, then he can start this battle up again. I'll get
some popcorn and observe from the sideline :-)

v3 on the way.

drew


> 
> >>  - "unsigned long addr" is changed to "u16 port";
> >>    x86 ought to have that and we should use different names if we need
> >>    different types, because behavior couldn't be the same then.
> > 
> > in*/out* should be portio for x86, and just aliases for read*/write*
> > mmio for other architectures.
> 
> Compile error would be the best implementation on arches without port
> space, because they shouldn't access interface for something that
> doesn't have a meaning for them.  Aliasing read*/write* is reasonable
> for arches that map port space into memory space.
> 
> >                               For mmio to work we may need 'unsigned long
> > addr', but that shouldn't stop x86 from defining its version as 'u16 port'.
> 
> It should.  The type system makes certain things easier, like using the
> expected value, and having two separate types for in*/out* defeats it
> without bringing any benefit.
> 
> If it turns out that we need more than u16 addr, x86 in*/out* would be
> better as 'unsigned long port' with 'BUG(port >= 64k)' inside.
> 
> > (Although Linux defines it as 'int' actually).
> > 
> > It does appear that in Linux arch/x86/include/asm/io.h doesn't include
> > asm-generic/io.h. So, if you'd prefer x86 to not include it here either,
> > then we can drop the inclusion and the '#define inb inb' type stuff from
> > lib/x86/asm/io.h.
> 
> Hm, I'd pick the mistake we do now.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-01-18 17:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15 16:51 [kvm-unit-tests PATCH v2 00/10] share pci-testdev with the framework Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 01/10] asm-generic: add portio accessors to io.h Andrew Jones
2016-01-15 21:34   ` Radim Krčmář
2016-01-18 13:52     ` Andrew Jones
2016-01-18 16:40       ` Radim Krčmář
2016-01-18 17:02         ` Andrew Jones [this message]
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 02/10] x86: move io.h to asm Andrew Jones
2016-01-15 21:39   ` Radim Krčmář
2016-01-18 13:55     ` Andrew Jones
2016-01-18 16:43       ` Radim Krčmář
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 03/10] x86: use common portio accessors from io.h Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 04/10] x86: pci.h: remove useless include Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 05/10] x86: move x86/pci to the common lib Andrew Jones
2016-01-15 21:57   ` Radim Krčmář
2016-01-18 13:59     ` Andrew Jones
2016-01-18 16:46       ` Radim Krčmář
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 06/10] x86: share pci-testdev hdr in " Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 07/10] lib/pci: make PCIDEVADDR_INVALID truly invalid Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 08/10] lib: add linux dir for kernel uapi headers Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 09/10] Revert "arm/arm64: import include/uapi/linux/psci.h" Andrew Jones
2016-01-15 16:51 ` [kvm-unit-tests PATCH v2 10/10] lib/linux: import pci_regs.h Andrew Jones
2016-01-15 21:57 ` [kvm-unit-tests PATCH v2 00/10] share pci-testdev with the framework Radim Krčmář
2016-01-18 14:01   ` Andrew Jones

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=20160118170216.GJ4075@hawk.localdomain \
    --to=drjones@redhat.com \
    --cc=agordeev@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.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