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 V4 05/10] Introduce HostPCIDevice to access a pci device on the host.
Date: Fri, 18 Nov 2011 10:06:22 -0500 [thread overview]
Message-ID: <20111118150622.GB17708@phenom.dumpdata.com> (raw)
In-Reply-To: <1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
On Thu, Nov 17, 2011 at 03:17:08PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
> Makefile.target | 1 +
> hw/host-pci-device.c | 279 ++++++++++++++++++++++++++++++++++++++++++++++++++
> hw/host-pci-device.h | 75 ++++++++++++++
> 3 files changed, 355 insertions(+), 0 deletions(-)
> create mode 100644 hw/host-pci-device.c
> create mode 100644 hw/host-pci-device.h
>
> diff --git a/Makefile.target b/Makefile.target
> index 2e881ce..e527c1b 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -220,6 +220,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
> obj-i386-$(CONFIG_XEN) += xen_platform.o
>
> # Xen PCI Passthrough
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>
> # Inter-VM PCI shared memory
> CONFIG_IVSHMEM =
> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
> new file mode 100644
> index 0000000..06f7761
> --- /dev/null
> +++ b/hw/host-pci-device.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (C) 2011 Citrix Ltd.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu-common.h"
> +#include "host-pci-device.h"
> +
> +#define PCI_MAX_EXT_CAP \
> + ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
> +
> +enum error_code {
> + ERROR_SYNTAX = 1,
> +};
> +
> +static int path_to(const HostPCIDevice *d,
> + const char *name, char *buf, ssize_t size)
> +{
> + return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
> + d->domain, d->bus, d->dev, d->func, name);
> +}
> +
> +static int get_resource(HostPCIDevice *d)
> +{
> + int i, rc = 0;
> + FILE *f;
> + char path[PATH_MAX];
> + unsigned long long start, end, flags, size;
> +
> + path_to(d, "resource", path, sizeof (path));
> + f = fopen(path, "r");
> + if (!f) {
> + fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
> + return -errno;
> + }
> +
> + for (i = 0; i < PCI_NUM_REGIONS; i++) {
> + if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
> + fprintf(stderr, "Error: Syntax error in %s\n", path);
> + rc = ERROR_SYNTAX;
> + break;
> + }
> + if (start) {
> + size = end - start + 1;
> + } else {
> + size = 0;
> + }
> +
> + if (i < PCI_ROM_SLOT) {
> + d->io_regions[i].base_addr = start;
> + d->io_regions[i].size = size;
> + d->io_regions[i].flags = flags;
> + } else {
> + d->rom.base_addr = start;
> + d->rom.size = size;
> + d->rom.flags = flags;
> + }
> + }
> +
> + fclose(f);
> + return rc;
> +}
> +
> +static int get_value(HostPCIDevice *d, const char *name, unsigned long *pvalue)
Perhaps 'get_hex_value'? You are just doing %lx, not %ld, so it has
to have to an exact format to get the contents right.
> +{
> + 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 get_resource can return 0, 1, or -errno. This one can return
0, or -1. Would it make sense to duplicate the -errno mechanism
that you employed in get_resources to have uniformity?
> + }
> + if (fscanf(f, "%lx\n", &value) != 1) {
> + fprintf(stderr, "Error: Syntax error in %s\n", path);
> + return -1;
> + }
> + fclose(f);
> + *pvalue = value;
> + return 0;
> +}
> +
> +static bool 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;
> +}
> +
> +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;
> +
> +again:
> + res = pread(fd, buf, len, pos);
> + if (res != len) {
> + if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
> + goto again;
> + }
> + fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",
Well, the comment says 'host_pci_config', but that is not the name
of the function. Perhaps replace it with '%s' and use __func__
as one of the parameters?
> + strerror(errno), fd);
> + return -errno;
> + }
> + return 0;
> +}
> +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;
> +
> +again:
> + res = pwrite(fd, buf, len, pos);
> + if (res != len) {
> + if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
> + goto again;
> + }
> + fprintf(stderr, "host_pci_config: write failed: %s\n",
> + strerror(errno));
> + return -errno;
> + }
> + return 0;
> +}
> +
> +int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
> +{
> + uint8_t buf;
> + if (host_pci_config_read(d, pos, &buf, 1)) {
> + return -1;
Would it make sense to use the nice enum you decleraed at the
top of the file? Or not?
next prev parent reply other threads:[~2011-11-18 15:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 15:17 [Qemu-devel] [PATCH V4 00/10] Xen PCI Passthrough Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 01/10] pci_ids: Add INTEL_82599_VF id Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 02/10] pci_regs: Fix value of PCI_EXP_TYPE_RC_EC Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 03/10] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 04/10] configure: Introduce --enable-xen-pci-passthrough Anthony PERARD
2011-11-18 14:53 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 05/10] Introduce HostPCIDevice to access a pci device on the host Anthony PERARD
2011-11-18 15:06 ` Konrad Rzeszutek Wilk [this message]
2011-11-23 18:25 ` [Qemu-devel] [Xen-devel] " Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 06/10] pci.c: Add pci_check_bar_overlap Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 07/10] Introduce Xen PCI Passthrough, qdevice (1/3) Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 08/10] Introduce Xen PCI Passthrough, PCI config space helpers (2/3) Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 09/10] Introduce apic-msidef.h Anthony PERARD
2011-11-17 15:17 ` [Qemu-devel] [PATCH V4 10/10] Introduce Xen PCI Passthrough, MSI (3/3) Anthony PERARD
2011-11-18 10:37 ` [Qemu-devel] [PATCH V4 00/10] Xen PCI Passthrough Stefano Stabellini
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=20111118150622.GB17708@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).