Re: [PATCH kvm-unit-tests 06/17] pci: introduce struct pci_dev

[Andrew Jones <drjones@redhat.com>]

On Tue, Nov 08, 2016 at 01:05:11AM +0800, Peter Xu wrote:
> On Fri, Nov 04, 2016 at 05:41:01PM +0100, Andrew Jones wrote:
> 
> [...]
> 
> > > +void pci_dev_init(struct pci_dev *dev, pcidevaddr_t bdf)
> > > +{
> > > +       memset(dev, 0, sizeof(*dev));
> > > +       dev->pci_bdf = bdf;
> > 
> > Hmm, bdf means bus-device-function, correct? We're not passing a "bdf"
> > in as the second argument to this function though. We're only passing
> > devid, assuming bus=0, fn=0. If you'd prefer we stop the bus,fn zero
> > assumption, then I think a precursor patch to this should be to change
> > our current handle type, pcidevaddr_t, to a "bdf_t".
> 
> I thought pcidevaddr_t means bdf? That's a wild guess of me from its
> size, as it's defined as:
> 
>   typedef uint16_t pcidevaddr_t;
> 
> uint16_t makes it looks more like bdf rather than devfn. For devfn,
> uint8_t suites better.
> 
> And what I mean here is to pass in the bdf of the device, not devfn
> only (in our case, devfn is always bdf though, since we are only
> supporting bus number zero).

see lib/x86/asm/pci.h:pci_config_read how 'dev' gets used, it's only dev.

> 
> > 
> > > +}
> > > +
> > >  /* Scan bus look for a specific device. Only bus 0 scanned for now. */
> > > -pcidevaddr_t pci_find_dev(uint16_t vendor_id, uint16_t device_id)
> > > +int pci_find_dev(struct pci_dev *pci_dev, uint16_t vendor_id, uint16_t device_id)
> > >  {
> > >  	pcidevaddr_t dev;
> > >  
> > > -	for (dev = 0; dev < 256; ++dev) {
> > > +	for (dev = 0; dev < PCI_DEVFN_MAX; ++dev) {
> > 
> > Why introduce this PCI_DEVFN_MAX define?
> 
> Because I think this value might be re-used in the future in other
> parts of the codes, so I defined a macro instead of using the raw
> number here.
> 
> > 
> > >  		if (pci_config_readw(dev, PCI_VENDOR_ID) == vendor_id &&
> > > -		    pci_config_readw(dev, PCI_DEVICE_ID) == device_id)
> > > -			return dev;
> > > +		    pci_config_readw(dev, PCI_DEVICE_ID) == device_id) {
> > > +			pci_dev_init(pci_dev, dev);
> > > +			return 0;
> > > +		}
> > >  	}
> > >  
> > > -	return PCIDEVADDR_INVALID;
> > > +	return -1;
> > 
> > Why not use bool for the ret type; true=good, false=bad?
> 
> True/false looks more direct, but zero/non-zero wins when in the
> future we want to add more error codes than -1. Both work for me. :)
> 
> [...]
> 
> > > +struct pci_dev {
> > > +	uint16_t pci_bdf;
> > 
> > No need for 'pci_' in the bdf name. It's whole name already has it,
> > pci_dev.bdf
> 
> Yes, actually this is something of my own "bad" habit. I used to add
> xxx_ prefix for better tag generations. When I read some big C repos
> like Linux, I see lots of duplicated field names for different
> structs/unions. For example, when I want to see codes related to
> StructA.FieldX, cscope will always tell me something more than this
> (rather than giving me StructA.FieldX, it gives me
> Struct[ABCDE..].FieldX). Then I need to pick out where StructA is.
> That's sometimes annoying, which depends on the length of the tag
> list. So I prefer to add this kind of prefix in the codes.
> 
> Actually when I read some other codes (IIUC FreeBSD kernel), I see
> that this "bad" technique is used as well with very short prefix,
> e.g., for a struct called "net_filter" and field called "users", it
> may be defined as:
> 
>   net_filter.nf_users
> 
> So the "nf_" prefix is the short form of "net_filter", and it can be
> used to distinguish the net_filter "users" fields with other "users"
> ones.
> 
> Here "pci" is short enough IMHO, so I prefixed it.
> 
> Not sure whether it's a good idea though.

Seems like overkill for kvm-unit-tests.

> 
> [...]
> 
> > I'm OK with introducing the pci_dev struct, but let's not switch over to
> > it from our other handle for everything all at once. I'd rather only
> > switch functions that will need more state than just devid/bdf. Anywhere
> > we never do then I think expecting the caller to call like
> > pci_foo(pcidev->bdf, ...) is reasonable.
> 
> Agree. That's some point I want to achieve. E.g., for
> pci_dev_exists(), I kept the old interface since it suites better
> IMHO. Also for the pci_config_*() APIs as mentioned in the commit
> message.

Let's keep the passing of the struct down to the minimum.

Thanks,
drew