From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
QEMU-devel <qemu-devel@nongnu.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH V3 02/10] Introduce HostPCIDevice to access a pci device on the host.
Date: Fri, 4 Nov 2011 13:49:24 -0400 [thread overview]
Message-ID: <20111104174924.GA21390@phenom.dumpdata.com> (raw)
In-Reply-To: <1319814456-8158-3-git-send-email-anthony.perard@citrix.com>
> +static unsigned long get_value(HostPCIDevice *d, const char *name)
> +{
> + char path[PATH_MAX];
> + FILE *f;
> + unsigned long value;
> +
> + path_to(d, name, path, sizeof (path));
> + f = fopen(path, "r");
> + if (!f) {
> + fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
> + return -1;
So the decleration is 'unsigned long' but you return -1 here.
Should the decleration be 'signed long' ?
Or perhaps return the value as parameter and return zero for success
and <= 0 for failure?
> + }
> + if (fscanf(f, "%lx\n", &value) != 1) {
> + fprintf(stderr, "Error: Syntax error in %s\n", path);
> + value = -1;
> + }
> + fclose(f);
> + return value;
> +}
> +
> +static int pci_dev_is_virtfn(HostPCIDevice *d)
> +{
> + int rc;
> + char path[PATH_MAX];
> + struct stat buf;
> +
> + path_to(d, "physfn", path, sizeof (path));
> + rc = !stat(path, &buf);
> +
> + return rc;
Seems like this could be a 'bool'?
> +}
> +
> +static int host_pci_config_fd(HostPCIDevice *d)
> +{
> + char path[PATH_MAX];
> +
> + if (d->config_fd < 0) {
> + path_to(d, "config", path, sizeof (path));
> + d->config_fd = open(path, O_RDWR);
> + if (d->config_fd < 0) {
> + fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
> + path, strerror(errno));
> + }
> + }
> + return d->config_fd;
> +}
> +static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
> +{
> + int fd = host_pci_config_fd(d);
> + int res = 0;
> +
> + res = pread(fd, buf, len, pos);
> + if (res < 0) {
> + fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",
> + strerror(errno), fd);
> + return -1;
> + }
> + return res;
> +}
> +static int host_pci_config_write(HostPCIDevice *d,
> + int pos, const void *buf, int len)
> +{
> + int fd = host_pci_config_fd(d);
> + int res = 0;
> +
> + res = pwrite(fd, buf, len, pos);
> + if (res < 0) {
> + fprintf(stderr, "host_pci_config: write failed: %s\n",
> + strerror(errno));
> + return -1;
> + }
> + return res;
> +}
> +
> +uint8_t host_pci_get_byte(HostPCIDevice *d, int pos)
> +{
> + uint8_t buf;
> + host_pci_config_read(d, pos, &buf, 1);
Not checking the return value?
> + return buf;
> +}
> +uint16_t host_pci_get_word(HostPCIDevice *d, int pos)
> +{
> + uint16_t buf;
> + host_pci_config_read(d, pos, &buf, 2);
Here as well?
> + return le16_to_cpu(buf);
So if we can't read those buffers, won't that mean we end up with
garbage in buf? As we haven't actually written anything to it?
Perhaps we should do:
if (host_pci..() < 0)
return 0;
... normal case?
> +}
> +uint32_t host_pci_get_long(HostPCIDevice *d, int pos)
> +{
> + uint32_t buf;
> + host_pci_config_read(d, pos, &buf, 4);
> + return le32_to_cpu(buf);
> +}
> +int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
> +{
> + return host_pci_config_read(d, pos, buf, len);
Oh, so that is called.. Hm, not much chance of returning an error there is.
Can we propage the errors in case there is some fundamental failure
when reading/writting the data stream? Say the PCI device gets
unplugged by the user.. won't pread return -EXIO?
> +}
> +
> +int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
> +{
> + return host_pci_config_write(d, pos, &data, 1);
> +}
> +int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
> +{
> + data = cpu_to_le16(data);
> + return host_pci_config_write(d, pos, &data, 2);
> +}
> +int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
> +{
> + data = cpu_to_le32(data);
> + return host_pci_config_write(d, pos, &data, 4);
> +}
> +int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
> +{
> + return host_pci_config_write(d, pos, buf, len);
> +}
> +
> +uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
> +{
> + uint32_t header = 0;
> + int max_cap = PCI_MAX_EXT_CAP;
> + int pos = PCI_CONFIG_SPACE_SIZE;
> +
> + do {
> + header = host_pci_get_long(d, pos);
> + /*
> + * If we have no capabilities, this is indicated by cap ID,
> + * cap version and next pointer all being 0.
> + */
> + if (header == 0) {
> + break;
> + }
> +
> + if (PCI_EXT_CAP_ID(header) == cap) {
> + return pos;
> + }
> +
> + pos = PCI_EXT_CAP_NEXT(header);
> + if (pos < PCI_CONFIG_SPACE_SIZE) {
> + break;
> + }
> +
> + max_cap--;
> + } while (max_cap > 0);
> +
> + return 0;
> +}
> +
> +HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
> +{
> + HostPCIDevice *d = NULL;
> +
> + d = g_new0(HostPCIDevice, 1);
> +
> + d->config_fd = -1;
> + d->domain = 0;
> + d->bus = bus;
> + d->dev = dev;
> + d->func = func;
> +
> + if (host_pci_config_fd(d) == -1) {
> + goto error;
> + }
> + if (get_resource(d) != 0) {
> + goto error;
> + }
> +
> + d->vendor_id = get_value(d, "vendor");
> + d->device_id = get_value(d, "device");
> + d->is_virtfn = pci_dev_is_virtfn(d);
> +
> + return d;
> +error:
> + if (d->config_fd >= 0) {
> + close(d->config_fd);
> + }
> + g_free(d);
> + return NULL;
> +}
> +
> +void host_pci_device_put(HostPCIDevice *d)
> +{
> + if (d->config_fd >= 0) {
> + close(d->config_fd);
> + }
> + g_free(d);
> +}
> diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
> new file mode 100644
> index 0000000..d79ba48
> --- /dev/null
> +++ b/hw/host-pci-device.h
> @@ -0,0 +1,75 @@
> +#ifndef HW_HOST_PCI_DEVICE
> +# define HW_HOST_PCI_DEVICE
> +
> +#include "pci.h"
> +
> +/*
> + * from linux/ioport.h
> + * IO resources have these defined flags.
> + */
> +#define IORESOURCE_BITS 0x000000ff /* Bus-specific bits */
> +
> +#define IORESOURCE_TYPE_BITS 0x00000f00 /* Resource type */
> +#define IORESOURCE_IO 0x00000100
> +#define IORESOURCE_MEM 0x00000200
> +#define IORESOURCE_IRQ 0x00000400
> +#define IORESOURCE_DMA 0x00000800
> +
> +#define IORESOURCE_PREFETCH 0x00001000 /* No side effects */
> +#define IORESOURCE_READONLY 0x00002000
> +#define IORESOURCE_CACHEABLE 0x00004000
> +#define IORESOURCE_RANGELENGTH 0x00008000
> +#define IORESOURCE_SHADOWABLE 0x00010000
> +
> +#define IORESOURCE_SIZEALIGN 0x00020000 /* size indicates alignment */
> +#define IORESOURCE_STARTALIGN 0x00040000 /* start field is alignment */
> +
> +#define IORESOURCE_MEM_64 0x00100000
> +
> + /* Userland may not map this resource */
> +#define IORESOURCE_EXCLUSIVE 0x08000000
> +#define IORESOURCE_DISABLED 0x10000000
> +#define IORESOURCE_UNSET 0x20000000
> +#define IORESOURCE_AUTO 0x40000000
> + /* Driver has marked this resource busy */
> +#define IORESOURCE_BUSY 0x80000000
> +
> +
> +typedef struct HostPCIIORegion {
> + unsigned long flags;
> + pcibus_t base_addr;
> + pcibus_t size;
> +} HostPCIIORegion;
> +
> +typedef struct HostPCIDevice {
> + uint16_t domain;
> + uint8_t bus;
> + uint8_t dev;
> + uint8_t func;
> +
> + uint16_t vendor_id;
> + uint16_t device_id;
> +
> + HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
> + HostPCIIORegion rom;
> +
> + bool is_virtfn;
> +
> + int config_fd;
> +} HostPCIDevice;
> +
> +HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
> +void host_pci_device_put(HostPCIDevice *pci_dev);
> +
> +uint8_t host_pci_get_byte(HostPCIDevice *d, int pos);
> +uint16_t host_pci_get_word(HostPCIDevice *d, int pos);
> +uint32_t host_pci_get_long(HostPCIDevice *d, int pos);
> +int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
> +int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
> +int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
> +int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
> +int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
> +
> +uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
> +
> +#endif /* !HW_HOST_PCI_DEVICE */
> --
> Anthony PERARD
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-11-04 17:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 15:07 [Qemu-devel] [PATCH V3 00/10] Xen PCI Passthrough Anthony PERARD
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 01/10] configure: Introduce --enable-xen-pci-passthrough Anthony PERARD
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 02/10] Introduce HostPCIDevice to access a pci device on the host Anthony PERARD
2011-11-04 17:49 ` Konrad Rzeszutek Wilk [this message]
2011-11-07 15:09 ` [Qemu-devel] [Xen-devel] " Anthony PERARD
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 03/10] pci.c: Add pci_check_bar_overlap Anthony PERARD
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 04/10] pci_ids: Add INTEL_82599_VF id Anthony PERARD
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 05/10] pci_regs: Fix value of PCI_EXP_TYPE_RC_EC Anthony PERARD
2011-11-04 7:36 ` Isaku Yamahata
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 06/10] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE Anthony PERARD
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 07/10] Introduce Xen PCI Passthrough, qdevice (1/3) Anthony PERARD
2011-11-08 12:56 ` Stefano Stabellini
2011-11-09 17:03 ` Anthony PERARD
2011-11-10 21:28 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2011-11-11 16:27 ` Anthony PERARD
2011-11-11 18:05 ` Konrad Rzeszutek Wilk
2011-11-14 11:09 ` Stefano Stabellini
2011-11-14 18:11 ` Konrad Rzeszutek Wilk
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 08/10] Introduce Xen PCI Passthrough, PCI config space helpers (2/3) Anthony PERARD
2011-11-08 12:57 ` Stefano Stabellini
2011-11-09 17:05 ` Anthony PERARD
2011-11-10 21:53 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2011-11-11 17:40 ` Anthony PERARD
2011-11-11 18:11 ` Konrad Rzeszutek Wilk
2011-11-11 20:37 ` Ian Campbell
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 09/10] Introduce apic-msidef.h Anthony PERARD
2011-11-08 12:57 ` Stefano Stabellini
2011-10-28 15:07 ` [Qemu-devel] [PATCH V3 10/10] Introduce Xen PCI Passthrough, MSI (3/3) Anthony PERARD
2011-11-10 22:10 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2011-11-11 19:18 ` Anthony PERARD
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=20111104174924.GA21390@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=anthony.perard@citrix.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.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).