[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Qemu-devel] [PATCH] Citrix PV Bus device
> -----Original Message----- > From: Andreas Färber [mailto:afaerber@xxxxxxx] > Sent: 02 July 2013 11:46 > To: Paul Durrant > Cc: qemu-devel@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx; Paolo Bonzini; > Michael S. Tsirkin > Subject: Re: [Qemu-devel] [PATCH] Citrix PV Bus device > > Am 02.07.2013 10:39, schrieb Paul Durrant: > > This patch introduces a new PCI device which will act as the binding point > > for Citrix branded PV drivers for Xen. > > The intention is that Citrix Windows PV drivers will be available on Windows > > Update and thus using the existing Xen platform PCI device as an anchor > > point is not desirable as that device has been ubiquitous in HVM guests for > > a long time and thus existing HVM guests running Windows would start > > automatically downloading drivers from Windows Update when this may > not be > > desired by either the host or guest admin. This device therefore acts as > > an opt-in for those wishing to deploy Citrix PV drivers. > > > > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> > > --- > > hw/i386/Makefile.objs | 1 + > > hw/i386/citrix_pv_bus.c | 122 > ++++++++++++++++++++++++++++++++++++++++++++++ > > include/hw/pci/pci_ids.h | 3 ++ > > 3 files changed, 126 insertions(+) > > create mode 100644 hw/i386/citrix_pv_bus.c > > > > diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs > > index 205d22e..8e28831 100644 > > --- a/hw/i386/Makefile.objs > > +++ b/hw/i386/Makefile.objs > > @@ -4,3 +4,4 @@ obj-y += pc.o pc_piix.o pc_q35.o > > obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o > > > > obj-y += kvmvapic.o > > +obj-y += citrix_pv_bus.o > > So the reason to place the device here is TARGET_PAGE_SIZE... We really > need a way to access that value from common code, somewhere down my > TODO > list. :/ > > > diff --git a/hw/i386/citrix_pv_bus.c b/hw/i386/citrix_pv_bus.c > > new file mode 100644 > > index 0000000..e1e0508 > > --- /dev/null > > +++ b/hw/i386/citrix_pv_bus.c > > @@ -0,0 +1,122 @@ > > +/* Copyright (c) Citrix Systems Inc. > > + * All rights reserved. > > + * > > + * Redistribution and use in source and binary forms, > > + * with or without modification, are permitted provided > > + * that the following conditions are met: > > + * > > + * * Redistributions of source code must retain the above > > + * copyright notice, this list of conditions and the > > + * following disclaimer. > > + * * Redistributions in binary form must reproduce the above > > + * copyright notice, this list of conditions and the > > + * following disclaimer in the documentation and/or other > > + * materials provided with the distribution. > > + * > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > > + * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, > > + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > > + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE > > + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR > > + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, > > + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > > + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > > + * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING > > + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > > + * SUCH DAMAGE. > > + */ > > + > > +#include "hw/hw.h" > > +#include "hw/pci/pci.h" > > + > > +typedef struct _CitrixPVBusDevice { > > Identifiers starting with underscore are supposedly reserved by > POSIX/C99, you can just use the same name as for the typedef. > Andreas, Thanks for the review. I'll modify that name as you suggest. > > + PCIDevice dev; > > /*< private >*/ > PCIDevice parent_obj; > /*< public >*/ > > please. More although still incomplete guidelines at: > > http://wiki.qemu.org/QOMConventions > Thanks for the pointer. > > + uint8_t revision; > > + uint32_t pages; > > + MemoryRegion mmio; > > +} CitrixPVBusDevice; > > + > > +static uint64_t citrix_pv_bus_mmio_read(void *opaque, hwaddr addr, > > + unsigned size) > > +{ > > + fprintf(stderr, "WARNING: read from address 0x" TARGET_FMT_plx > > + " in Citrix PV Bus MMIO BAR\n", addr); > > Possibly use the qemu_log() macros or a tracepoint? > I'm just looking at tracepoints now. That does seem like a cleaner approach. > > + > > + return ~(uint64_t)0; > > +} > > + > > +static void citrix_pv_bus_mmio_write(void *opaque, hwaddr addr, > > + uint64_t val, unsigned size) > > +{ > > + fprintf(stderr, "WARNING: write to address 0x" TARGET_FMT_plx > > + " in Citrix PV Bus MMIO BAR\n", addr); > > +} > > + > > +static const MemoryRegionOps citrix_pv_bus_mmio_ops = { > > + .read = &citrix_pv_bus_mmio_read, > > + .write = &citrix_pv_bus_mmio_write, > > + .endianness = DEVICE_NATIVE_ENDIAN, > > +}; > > + > > +static int citrix_pv_bus_init(PCIDevice *pci_dev) > > +{ > > + CitrixPVBusDevice *d = DO_UPCAST(CitrixPVBusDevice, dev, pci_dev); > > Please don't use DO_UPCAST() with QOM objects. Please introduce a > CITRIX_PV_BUS_DEVICE(obj) macro as described above and/or in > include/qom/object.h to avoid using the parent field's name in code. > Ok. > > + uint8_t *pci_conf; > > + uint64_t size; > > + > > + pci_conf = pci_dev->config; > > + > > + pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY); > > + pci_set_byte(pci_conf + PCI_REVISION_ID, d->revision); > > + > > + pci_config_set_prog_interface(pci_conf, 0); > > + > > + pci_conf[PCI_INTERRUPT_PIN] = 1; > > + > > + size = d->pages * TARGET_PAGE_SIZE; > > + memory_region_init_io(&d->mmio, &citrix_pv_bus_mmio_ops, d, > > + "citrix-bus-mmio", size); > > FYI Paolo will shortly merge a series that adds an owner as second > argument, i.e. pci_dev here. > > > + > > + pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_MEM_PREFETCH, > > + &d->mmio); > > + > > + return 0; > > Otherwise thanks for using pci_dev rather than d->dev, that'll make > converting this to QOM realize easier later. > > > +} > > + > > +static Property citrix_pv_bus_props[] = { > > + DEFINE_PROP_UINT8("revision", CitrixPVBusDevice, revision, 0x01), > > + DEFINE_PROP_UINT32("pages", CitrixPVBusDevice, pages, 128), > > + DEFINE_PROP_END_OF_LIST() > > +}; > > + > > +static void citrix_pv_bus_class_init(ObjectClass *klass, void *data) > > +{ > > + DeviceClass *dc = DEVICE_CLASS(klass); > > + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); > > + > > + k->init = citrix_pv_bus_init; > > + k->vendor_id = PCI_VENDOR_ID_CITRIX; > > + k->device_id = PCI_DEVICE_ID_CITRIX_PV_BUS; > > + k->class_id = PCI_CLASS_SYSTEM_OTHER; > > + k->subsystem_vendor_id = PCI_VENDOR_ID_CITRIX; > > + k->subsystem_id = PCI_DEVICE_ID_CITRIX_PV_BUS; > > + dc->desc = "Citrix PV Bus"; > > + dc->props = citrix_pv_bus_props; > > +} > > + > > +static const TypeInfo citrix_pv_bus_type_info = { > > + .name = "citrix-pv-bus", > > As part of the requested cast macro, please use a TYPE_... constant for > the string. I would suggest to not let a device type name end in -bus to > distinguish from actual QEMU busses (PCIBus, etc.). > > What exactly do you intend to do with this device? Are you planning to > derive further specialized devices? Having a bar that prints errors on > each access surely doesn't seem like the final goal? > Yes, further devices will be enumerated by the driver that binds to the device in Xen HVM domains. The MMIO region is there to reserve address space for 'special' pages such as the Xen grant table so any access to the region that makes it through to the device emulation code is actually a bug in the guest - hence the warning. Paul _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |