| Message ID | 1372930249-22916-1-git-send-email-paul.durrant@citrix.com |
|---|---|
| State | New |
| Headers | show |
On Thu, 4 Jul 2013, Paul Durrant wrote: > Introduces a new Xen PV PCI device which will act as a binding point for > PV drivers for Xen. > The device has parameterized vendor-id, device-id and revision to allow to > be configured as a binding point for any vendor's PV drivers. > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com> > Cc: Stefano Stabellini <stefano.stabellini@citrix.com> > Reviewed-by: Andreas Färber <afaerber@suse.de> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > > V5: > - Addresses comments from Andreas Färber > > V4: > - Renamed from 'Citrix PV Bus' to 'Xen PV Device' > - Paramaterized vendor-id and device-id as requested by Stefano Stabellini > > V3: > - Addresses comments from Anthony Liguori and Peter Maydell > > V2: > - Addresses comments from Andreas Farber and Paolo Bonzini > > hw/xen/Makefile.objs | 1 + > hw/xen/xen_pvdevice.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++ > include/hw/pci/pci_ids.h | 5 +- > trace-events | 4 ++ > 4 files changed, 139 insertions(+), 2 deletions(-) > create mode 100644 hw/xen/xen_pvdevice.c > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > index 2017560..cd2df6a 100644 > --- a/hw/xen/Makefile.objs > +++ b/hw/xen/Makefile.objs > @@ -1,5 +1,6 @@ > # xen backend driver support > common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o > +common-obj-y += xen_pvdevice.o > > obj-$(CONFIG_XEN_I386) += xen_platform.o xen_apic.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > diff --git a/hw/xen/xen_pvdevice.c b/hw/xen/xen_pvdevice.c > new file mode 100644 > index 0000000..93dfab2 > --- /dev/null > +++ b/hw/xen/xen_pvdevice.c > @@ -0,0 +1,131 @@ > +/* 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" > +#include "trace.h" > + > +#define TYPE_XEN_PV_DEVICE "xen-pvdevice" > + > +#define XEN_PV_DEVICE(obj) \ > + OBJECT_CHECK(XenPVDevice, (obj), TYPE_XEN_PV_DEVICE) > + > +typedef struct XenPVDevice { > + /*< private >*/ > + PCIDevice parent_obj; > + /*< public >*/ > + uint16_t vendor_id; > + uint16_t device_id; > + uint8_t revision; > + uint32_t size; > + MemoryRegion mmio; > +} XenPVDevice; > + > +static uint64_t xen_pv_mmio_read(void *opaque, hwaddr addr, > + unsigned size) > +{ > + trace_xen_pv_mmio_read(addr); > + > + return ~(uint64_t)0; > +} > + > +static void xen_pv_mmio_write(void *opaque, hwaddr addr, > + uint64_t val, unsigned size) > +{ > + trace_xen_pv_mmio_write(addr); > +} > + > +static const MemoryRegionOps xen_pv_mmio_ops = { > + .read = &xen_pv_mmio_read, > + .write = &xen_pv_mmio_write, > + .endianness = DEVICE_LITTLE_ENDIAN, > +}; > + > +static int xen_pv_init(PCIDevice *pci_dev) > +{ > + XenPVDevice *d = XEN_PV_DEVICE(pci_dev); > + uint8_t *pci_conf; > + > + pci_conf = pci_dev->config; > + > + pci_set_word(pci_conf + PCI_VENDOR_ID, d->vendor_id); > + pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, d->vendor_id); > + pci_set_word(pci_conf + PCI_DEVICE_ID, d->device_id); > + pci_set_word(pci_conf + PCI_SUBSYSTEM_ID, d->device_id); > + pci_set_byte(pci_conf + PCI_REVISION_ID, d->revision); > + > + pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY); > + > + pci_config_set_prog_interface(pci_conf, 0); > + > + pci_conf[PCI_INTERRUPT_PIN] = 1; > + > + memory_region_init_io(&d->mmio, &xen_pv_mmio_ops, d, > + "mmio", d->size); > + > + pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_MEM_PREFETCH, > + &d->mmio); > + > + return 0; > +} > + > +static Property xen_pv_props[] = { > + DEFINE_PROP_UINT16("vendor-id", XenPVDevice, vendor_id, PCI_VENDOR_ID_XEN), > + DEFINE_PROP_UINT16("device-id", XenPVDevice, device_id, PCI_DEVICE_ID_XEN_PVDEVICE), > + DEFINE_PROP_UINT8("revision", XenPVDevice, revision, 0x01), > + DEFINE_PROP_UINT32("size", XenPVDevice, size, 0x400000), > + DEFINE_PROP_END_OF_LIST() > +}; > + > +static void xen_pv_class_init(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); > + > + k->init = xen_pv_init; > + k->class_id = PCI_CLASS_SYSTEM_OTHER; > + dc->desc = "Xen PV Device"; > + dc->props = xen_pv_props; > +} > + > +static const TypeInfo xen_pv_type_info = { > + .name = TYPE_XEN_PV_DEVICE, > + .parent = TYPE_PCI_DEVICE, > + .instance_size = sizeof(XenPVDevice), > + .class_init = xen_pv_class_init, > +}; > + > +static void xen_pv_register_types(void) > +{ > + type_register_static(&xen_pv_type_info); > +} > + > +type_init(xen_pv_register_types) > diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h > index d8dc2f1..263bca3 100644 > --- a/include/hw/pci/pci_ids.h > +++ b/include/hw/pci/pci_ids.h > @@ -142,8 +142,9 @@ > > #define PCI_DEVICE_ID_INTEL_Q35_MCH 0x29c0 > > -#define PCI_VENDOR_ID_XEN 0x5853 > -#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 > +#define PCI_VENDOR_ID_XEN 0x5853 > +#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 > +#define PCI_DEVICE_ID_XEN_PVDEVICE 0x0002 > > #define PCI_VENDOR_ID_NEC 0x1033 > #define PCI_DEVICE_ID_NEC_UPD720200 0x0194 > diff --git a/trace-events b/trace-events > index c5f1ccb..0445853 100644 > --- a/trace-events > +++ b/trace-events > @@ -1161,3 +1161,7 @@ kvm_run_exit(int cpu_index, uint32_t reason) "cpu_index %d, reason %d" > # qom/object.c > object_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" > object_class_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" > + > +# hw/xen/xen_pvdevice.c > +xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space (address %"PRIx64")" > +xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space (address %"PRIx64")" > -- > 1.7.10.4 >
On Thu, Jul 04, 2013 at 01:52:46PM +0100, Stefano Stabellini wrote: > On Thu, 4 Jul 2013, Paul Durrant wrote: > > Introduces a new Xen PV PCI device which will act as a binding point for > > PV drivers for Xen. > > The device has parameterized vendor-id, device-id and revision to allow to > > be configured as a binding point for any vendor's PV drivers. > > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com> > > Cc: Stefano Stabellini <stefano.stabellini@citrix.com> > > Reviewed-by: Andreas Färber <afaerber@suse.de> > > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Matt Wilson <msw@amazon.com> > > > > V5: > > - Addresses comments from Andreas Färber > > > > V4: > > - Renamed from 'Citrix PV Bus' to 'Xen PV Device' > > - Paramaterized vendor-id and device-id as requested by Stefano Stabellini > > > > V3: > > - Addresses comments from Anthony Liguori and Peter Maydell > > > > V2: > > - Addresses comments from Andreas Farber and Paolo Bonzini > > > > hw/xen/Makefile.objs | 1 + > > hw/xen/xen_pvdevice.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++ > > include/hw/pci/pci_ids.h | 5 +- > > trace-events | 4 ++ > > 4 files changed, 139 insertions(+), 2 deletions(-) > > create mode 100644 hw/xen/xen_pvdevice.c > > > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > > index 2017560..cd2df6a 100644 > > --- a/hw/xen/Makefile.objs > > +++ b/hw/xen/Makefile.objs > > @@ -1,5 +1,6 @@ > > # xen backend driver support > > common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o > > +common-obj-y += xen_pvdevice.o > > > > obj-$(CONFIG_XEN_I386) += xen_platform.o xen_apic.o > > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > > diff --git a/hw/xen/xen_pvdevice.c b/hw/xen/xen_pvdevice.c > > new file mode 100644 > > index 0000000..93dfab2 > > --- /dev/null > > +++ b/hw/xen/xen_pvdevice.c > > @@ -0,0 +1,131 @@ > > +/* 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" > > +#include "trace.h" > > + > > +#define TYPE_XEN_PV_DEVICE "xen-pvdevice" > > + > > +#define XEN_PV_DEVICE(obj) \ > > + OBJECT_CHECK(XenPVDevice, (obj), TYPE_XEN_PV_DEVICE) > > + > > +typedef struct XenPVDevice { > > + /*< private >*/ > > + PCIDevice parent_obj; > > + /*< public >*/ > > + uint16_t vendor_id; > > + uint16_t device_id; > > + uint8_t revision; > > + uint32_t size; > > + MemoryRegion mmio; > > +} XenPVDevice; > > + > > +static uint64_t xen_pv_mmio_read(void *opaque, hwaddr addr, > > + unsigned size) > > +{ > > + trace_xen_pv_mmio_read(addr); > > + > > + return ~(uint64_t)0; > > +} > > + > > +static void xen_pv_mmio_write(void *opaque, hwaddr addr, > > + uint64_t val, unsigned size) > > +{ > > + trace_xen_pv_mmio_write(addr); > > +} > > + > > +static const MemoryRegionOps xen_pv_mmio_ops = { > > + .read = &xen_pv_mmio_read, > > + .write = &xen_pv_mmio_write, > > + .endianness = DEVICE_LITTLE_ENDIAN, > > +}; > > + > > +static int xen_pv_init(PCIDevice *pci_dev) > > +{ > > + XenPVDevice *d = XEN_PV_DEVICE(pci_dev); > > + uint8_t *pci_conf; > > + > > + pci_conf = pci_dev->config; > > + > > + pci_set_word(pci_conf + PCI_VENDOR_ID, d->vendor_id); > > + pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, d->vendor_id); > > + pci_set_word(pci_conf + PCI_DEVICE_ID, d->device_id); > > + pci_set_word(pci_conf + PCI_SUBSYSTEM_ID, d->device_id); > > + pci_set_byte(pci_conf + PCI_REVISION_ID, d->revision); > > + > > + pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY); > > + > > + pci_config_set_prog_interface(pci_conf, 0); > > + > > + pci_conf[PCI_INTERRUPT_PIN] = 1; > > + > > + memory_region_init_io(&d->mmio, &xen_pv_mmio_ops, d, > > + "mmio", d->size); > > + > > + pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_MEM_PREFETCH, > > + &d->mmio); > > + > > + return 0; > > +} > > + > > +static Property xen_pv_props[] = { > > + DEFINE_PROP_UINT16("vendor-id", XenPVDevice, vendor_id, PCI_VENDOR_ID_XEN), > > + DEFINE_PROP_UINT16("device-id", XenPVDevice, device_id, PCI_DEVICE_ID_XEN_PVDEVICE), > > + DEFINE_PROP_UINT8("revision", XenPVDevice, revision, 0x01), > > + DEFINE_PROP_UINT32("size", XenPVDevice, size, 0x400000), > > + DEFINE_PROP_END_OF_LIST() > > +}; > > + > > +static void xen_pv_class_init(ObjectClass *klass, void *data) > > +{ > > + DeviceClass *dc = DEVICE_CLASS(klass); > > + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); > > + > > + k->init = xen_pv_init; > > + k->class_id = PCI_CLASS_SYSTEM_OTHER; > > + dc->desc = "Xen PV Device"; > > + dc->props = xen_pv_props; > > +} > > + > > +static const TypeInfo xen_pv_type_info = { > > + .name = TYPE_XEN_PV_DEVICE, > > + .parent = TYPE_PCI_DEVICE, > > + .instance_size = sizeof(XenPVDevice), > > + .class_init = xen_pv_class_init, > > +}; > > + > > +static void xen_pv_register_types(void) > > +{ > > + type_register_static(&xen_pv_type_info); > > +} > > + > > +type_init(xen_pv_register_types) > > diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h > > index d8dc2f1..263bca3 100644 > > --- a/include/hw/pci/pci_ids.h > > +++ b/include/hw/pci/pci_ids.h > > @@ -142,8 +142,9 @@ > > > > #define PCI_DEVICE_ID_INTEL_Q35_MCH 0x29c0 > > > > -#define PCI_VENDOR_ID_XEN 0x5853 > > -#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 > > +#define PCI_VENDOR_ID_XEN 0x5853 > > +#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 > > +#define PCI_DEVICE_ID_XEN_PVDEVICE 0x0002 > > > > #define PCI_VENDOR_ID_NEC 0x1033 > > #define PCI_DEVICE_ID_NEC_UPD720200 0x0194 > > diff --git a/trace-events b/trace-events > > index c5f1ccb..0445853 100644 > > --- a/trace-events > > +++ b/trace-events > > @@ -1161,3 +1161,7 @@ kvm_run_exit(int cpu_index, uint32_t reason) "cpu_index %d, reason %d" > > # qom/object.c > > object_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" > > object_class_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" > > + > > +# hw/xen/xen_pvdevice.c > > +xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space (address %"PRIx64")" > > +xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space (address %"PRIx64")" > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes: > On Thu, 4 Jul 2013, Paul Durrant wrote: >> Introduces a new Xen PV PCI device which will act as a binding point for >> PV drivers for Xen. >> The device has parameterized vendor-id, device-id and revision to allow to >> be configured as a binding point for any vendor's PV drivers. >> >> Signed-off-by: Paul Durrant <paul.durrant@citrix.com> >> Cc: Stefano Stabellini <stefano.stabellini@citrix.com> >> Reviewed-by: Andreas Färber <afaerber@suse.de> > > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> (Just a nit and responding because this happens commonly). You probably mean Reviewed-by. Acked-by really means, "I am not the maintainer of this area, I have not reviewed this patch, but I am generally okay with the idea as best I can tell." It's a very low vote of confidence. I wouldn't apply a patch that only had Acked-bys. OTOH, Reviewed-by means, "I have reviewed the patch and believe it works as described and meets project guidelines". Based on your review of V4, pretty sure that's what you mean here. https://github.com/torvalds/linux/blob/master/Documentation/SubmittingPatches#L392 The distinction matters in practice because I have scripts to track patches based on whether they've received Reviewed-bys or not. I'm often running into cases where people are Acked-by'ing instead of Reviewed-by'ing patches and then wondering why they haven't gotten merged... Since this patch would come through your tree anyway, it doesn't matter in practice for this patch. I'll get off my soapbox now :-) Regards, Anthony Liguori > > >> >> V5: >> - Addresses comments from Andreas Färber >> >> V4: >> - Renamed from 'Citrix PV Bus' to 'Xen PV Device' >> - Paramaterized vendor-id and device-id as requested by Stefano Stabellini >> >> V3: >> - Addresses comments from Anthony Liguori and Peter Maydell >> >> V2: >> - Addresses comments from Andreas Farber and Paolo Bonzini >> >> hw/xen/Makefile.objs | 1 + >> hw/xen/xen_pvdevice.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++ >> include/hw/pci/pci_ids.h | 5 +- >> trace-events | 4 ++ >> 4 files changed, 139 insertions(+), 2 deletions(-) >> create mode 100644 hw/xen/xen_pvdevice.c >> >> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs >> index 2017560..cd2df6a 100644 >> --- a/hw/xen/Makefile.objs >> +++ b/hw/xen/Makefile.objs >> @@ -1,5 +1,6 @@ >> # xen backend driver support >> common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o >> +common-obj-y += xen_pvdevice.o >> >> obj-$(CONFIG_XEN_I386) += xen_platform.o xen_apic.o >> obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o >> diff --git a/hw/xen/xen_pvdevice.c b/hw/xen/xen_pvdevice.c >> new file mode 100644 >> index 0000000..93dfab2 >> --- /dev/null >> +++ b/hw/xen/xen_pvdevice.c >> @@ -0,0 +1,131 @@ >> +/* 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" >> +#include "trace.h" >> + >> +#define TYPE_XEN_PV_DEVICE "xen-pvdevice" >> + >> +#define XEN_PV_DEVICE(obj) \ >> + OBJECT_CHECK(XenPVDevice, (obj), TYPE_XEN_PV_DEVICE) >> + >> +typedef struct XenPVDevice { >> + /*< private >*/ >> + PCIDevice parent_obj; >> + /*< public >*/ >> + uint16_t vendor_id; >> + uint16_t device_id; >> + uint8_t revision; >> + uint32_t size; >> + MemoryRegion mmio; >> +} XenPVDevice; >> + >> +static uint64_t xen_pv_mmio_read(void *opaque, hwaddr addr, >> + unsigned size) >> +{ >> + trace_xen_pv_mmio_read(addr); >> + >> + return ~(uint64_t)0; >> +} >> + >> +static void xen_pv_mmio_write(void *opaque, hwaddr addr, >> + uint64_t val, unsigned size) >> +{ >> + trace_xen_pv_mmio_write(addr); >> +} >> + >> +static const MemoryRegionOps xen_pv_mmio_ops = { >> + .read = &xen_pv_mmio_read, >> + .write = &xen_pv_mmio_write, >> + .endianness = DEVICE_LITTLE_ENDIAN, >> +}; >> + >> +static int xen_pv_init(PCIDevice *pci_dev) >> +{ >> + XenPVDevice *d = XEN_PV_DEVICE(pci_dev); >> + uint8_t *pci_conf; >> + >> + pci_conf = pci_dev->config; >> + >> + pci_set_word(pci_conf + PCI_VENDOR_ID, d->vendor_id); >> + pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, d->vendor_id); >> + pci_set_word(pci_conf + PCI_DEVICE_ID, d->device_id); >> + pci_set_word(pci_conf + PCI_SUBSYSTEM_ID, d->device_id); >> + pci_set_byte(pci_conf + PCI_REVISION_ID, d->revision); >> + >> + pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY); >> + >> + pci_config_set_prog_interface(pci_conf, 0); >> + >> + pci_conf[PCI_INTERRUPT_PIN] = 1; >> + >> + memory_region_init_io(&d->mmio, &xen_pv_mmio_ops, d, >> + "mmio", d->size); >> + >> + pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_MEM_PREFETCH, >> + &d->mmio); >> + >> + return 0; >> +} >> + >> +static Property xen_pv_props[] = { >> + DEFINE_PROP_UINT16("vendor-id", XenPVDevice, vendor_id, PCI_VENDOR_ID_XEN), >> + DEFINE_PROP_UINT16("device-id", XenPVDevice, device_id, PCI_DEVICE_ID_XEN_PVDEVICE), >> + DEFINE_PROP_UINT8("revision", XenPVDevice, revision, 0x01), >> + DEFINE_PROP_UINT32("size", XenPVDevice, size, 0x400000), >> + DEFINE_PROP_END_OF_LIST() >> +}; >> + >> +static void xen_pv_class_init(ObjectClass *klass, void *data) >> +{ >> + DeviceClass *dc = DEVICE_CLASS(klass); >> + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); >> + >> + k->init = xen_pv_init; >> + k->class_id = PCI_CLASS_SYSTEM_OTHER; >> + dc->desc = "Xen PV Device"; >> + dc->props = xen_pv_props; >> +} >> + >> +static const TypeInfo xen_pv_type_info = { >> + .name = TYPE_XEN_PV_DEVICE, >> + .parent = TYPE_PCI_DEVICE, >> + .instance_size = sizeof(XenPVDevice), >> + .class_init = xen_pv_class_init, >> +}; >> + >> +static void xen_pv_register_types(void) >> +{ >> + type_register_static(&xen_pv_type_info); >> +} >> + >> +type_init(xen_pv_register_types) >> diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h >> index d8dc2f1..263bca3 100644 >> --- a/include/hw/pci/pci_ids.h >> +++ b/include/hw/pci/pci_ids.h >> @@ -142,8 +142,9 @@ >> >> #define PCI_DEVICE_ID_INTEL_Q35_MCH 0x29c0 >> >> -#define PCI_VENDOR_ID_XEN 0x5853 >> -#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 >> +#define PCI_VENDOR_ID_XEN 0x5853 >> +#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 >> +#define PCI_DEVICE_ID_XEN_PVDEVICE 0x0002 >> >> #define PCI_VENDOR_ID_NEC 0x1033 >> #define PCI_DEVICE_ID_NEC_UPD720200 0x0194 >> diff --git a/trace-events b/trace-events >> index c5f1ccb..0445853 100644 >> --- a/trace-events >> +++ b/trace-events >> @@ -1161,3 +1161,7 @@ kvm_run_exit(int cpu_index, uint32_t reason) "cpu_index %d, reason %d" >> # qom/object.c >> object_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" >> object_class_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" >> + >> +# hw/xen/xen_pvdevice.c >> +xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space (address %"PRIx64")" >> +xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space (address %"PRIx64")" >> -- >> 1.7.10.4 >>
Paul Durrant <paul.durrant@citrix.com> writes: > Introduces a new Xen PV PCI device which will act as a binding point for > PV drivers for Xen. > The device has parameterized vendor-id, device-id and revision to allow to > be configured as a binding point for any vendor's PV drivers. > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com> > Cc: Stefano Stabellini <stefano.stabellini@citrix.com> > Reviewed-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Anthony Liguori <aliguori@us.ibm.com> Regards, Anthony Liguori > --- > > V5: > - Addresses comments from Andreas Färber > > V4: > - Renamed from 'Citrix PV Bus' to 'Xen PV Device' > - Paramaterized vendor-id and device-id as requested by Stefano Stabellini > > V3: > - Addresses comments from Anthony Liguori and Peter Maydell > > V2: > - Addresses comments from Andreas Farber and Paolo Bonzini > > hw/xen/Makefile.objs | 1 + > hw/xen/xen_pvdevice.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++ > include/hw/pci/pci_ids.h | 5 +- > trace-events | 4 ++ > 4 files changed, 139 insertions(+), 2 deletions(-) > create mode 100644 hw/xen/xen_pvdevice.c > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > index 2017560..cd2df6a 100644 > --- a/hw/xen/Makefile.objs > +++ b/hw/xen/Makefile.objs > @@ -1,5 +1,6 @@ > # xen backend driver support > common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o > +common-obj-y += xen_pvdevice.o > > obj-$(CONFIG_XEN_I386) += xen_platform.o xen_apic.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > diff --git a/hw/xen/xen_pvdevice.c b/hw/xen/xen_pvdevice.c > new file mode 100644 > index 0000000..93dfab2 > --- /dev/null > +++ b/hw/xen/xen_pvdevice.c > @@ -0,0 +1,131 @@ > +/* 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" > +#include "trace.h" > + > +#define TYPE_XEN_PV_DEVICE "xen-pvdevice" > + > +#define XEN_PV_DEVICE(obj) \ > + OBJECT_CHECK(XenPVDevice, (obj), TYPE_XEN_PV_DEVICE) > + > +typedef struct XenPVDevice { > + /*< private >*/ > + PCIDevice parent_obj; > + /*< public >*/ > + uint16_t vendor_id; > + uint16_t device_id; > + uint8_t revision; > + uint32_t size; > + MemoryRegion mmio; > +} XenPVDevice; > + > +static uint64_t xen_pv_mmio_read(void *opaque, hwaddr addr, > + unsigned size) > +{ > + trace_xen_pv_mmio_read(addr); > + > + return ~(uint64_t)0; > +} > + > +static void xen_pv_mmio_write(void *opaque, hwaddr addr, > + uint64_t val, unsigned size) > +{ > + trace_xen_pv_mmio_write(addr); > +} > + > +static const MemoryRegionOps xen_pv_mmio_ops = { > + .read = &xen_pv_mmio_read, > + .write = &xen_pv_mmio_write, > + .endianness = DEVICE_LITTLE_ENDIAN, > +}; > + > +static int xen_pv_init(PCIDevice *pci_dev) > +{ > + XenPVDevice *d = XEN_PV_DEVICE(pci_dev); > + uint8_t *pci_conf; > + > + pci_conf = pci_dev->config; > + > + pci_set_word(pci_conf + PCI_VENDOR_ID, d->vendor_id); > + pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, d->vendor_id); > + pci_set_word(pci_conf + PCI_DEVICE_ID, d->device_id); > + pci_set_word(pci_conf + PCI_SUBSYSTEM_ID, d->device_id); > + pci_set_byte(pci_conf + PCI_REVISION_ID, d->revision); > + > + pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY); > + > + pci_config_set_prog_interface(pci_conf, 0); > + > + pci_conf[PCI_INTERRUPT_PIN] = 1; > + > + memory_region_init_io(&d->mmio, &xen_pv_mmio_ops, d, > + "mmio", d->size); > + > + pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_MEM_PREFETCH, > + &d->mmio); > + > + return 0; > +} > + > +static Property xen_pv_props[] = { > + DEFINE_PROP_UINT16("vendor-id", XenPVDevice, vendor_id, PCI_VENDOR_ID_XEN), > + DEFINE_PROP_UINT16("device-id", XenPVDevice, device_id, PCI_DEVICE_ID_XEN_PVDEVICE), > + DEFINE_PROP_UINT8("revision", XenPVDevice, revision, 0x01), > + DEFINE_PROP_UINT32("size", XenPVDevice, size, 0x400000), > + DEFINE_PROP_END_OF_LIST() > +}; > + > +static void xen_pv_class_init(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); > + > + k->init = xen_pv_init; > + k->class_id = PCI_CLASS_SYSTEM_OTHER; > + dc->desc = "Xen PV Device"; > + dc->props = xen_pv_props; > +} > + > +static const TypeInfo xen_pv_type_info = { > + .name = TYPE_XEN_PV_DEVICE, > + .parent = TYPE_PCI_DEVICE, > + .instance_size = sizeof(XenPVDevice), > + .class_init = xen_pv_class_init, > +}; > + > +static void xen_pv_register_types(void) > +{ > + type_register_static(&xen_pv_type_info); > +} > + > +type_init(xen_pv_register_types) > diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h > index d8dc2f1..263bca3 100644 > --- a/include/hw/pci/pci_ids.h > +++ b/include/hw/pci/pci_ids.h > @@ -142,8 +142,9 @@ > > #define PCI_DEVICE_ID_INTEL_Q35_MCH 0x29c0 > > -#define PCI_VENDOR_ID_XEN 0x5853 > -#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 > +#define PCI_VENDOR_ID_XEN 0x5853 > +#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 > +#define PCI_DEVICE_ID_XEN_PVDEVICE 0x0002 > > #define PCI_VENDOR_ID_NEC 0x1033 > #define PCI_DEVICE_ID_NEC_UPD720200 0x0194 > diff --git a/trace-events b/trace-events > index c5f1ccb..0445853 100644 > --- a/trace-events > +++ b/trace-events > @@ -1161,3 +1161,7 @@ kvm_run_exit(int cpu_index, uint32_t reason) "cpu_index %d, reason %d" > # qom/object.c > object_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" > object_class_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" > + > +# hw/xen/xen_pvdevice.c > +xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space (address %"PRIx64")" > +xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space (address %"PRIx64")" > -- > 1.7.10.4
On 8 July 2013 15:04, Anthony Liguori <anthony@codemonkey.ws> wrote: > (Just a nit and responding because this happens commonly). > > You probably mean Reviewed-by. Acked-by really means, "I am not the > maintainer of this area, I have not reviewed this patch, but I am > generally okay with the idea as best I can tell." Don't you mean "I *am* the maintainer of this area" ? I've always assumed it means "as the maintainer I have a potential veto over this code change and I am explicitly not exercising it even though I may not have done a complete review and/or test"... > It's a very low vote of confidence. I wouldn't apply a patch that only > had Acked-bys. > > OTOH, Reviewed-by means, "I have reviewed the patch and believe it works > as described and meets project guidelines". Based on your review of V4, > pretty sure that's what you mean here. > > https://github.com/torvalds/linux/blob/master/Documentation/SubmittingPatches#L392 > > The distinction matters in practice because I have scripts to track > patches based on whether they've received Reviewed-bys or not. I'm > often running into cases where people are Acked-by'ing instead of > Reviewed-by'ing patches and then wondering why they haven't gotten > merged... I think Andreas is the major exponent of the idea that "acked-by" is stronger than "reviewed-by". Regardless, I think we should standardise on what we mean by both tags. (Alas the kernel docs are not entirely clear about acked-by, though the meaning of reviewed-by is certainly clear.) thanks -- PMM
--On 8 July 2013 15:10:49 +0100 Peter Maydell <peter.maydell@linaro.org> wrote: >> You probably mean Reviewed-by. Acked-by really means, "I am not the >> maintainer of this area, I have not reviewed this patch, but I am >> generally okay with the idea as best I can tell." > > Don't you mean "I *am* the maintainer of this area" ? I've always > assumed it means "as the maintainer I have a potential veto over > this code change and I am explicitly not exercising it even though > I may not have done a complete review and/or test"... Really? That would imply no one should add Acked-By except maintainers. That's not right according to: https://github.com/torvalds/linux/blob/master/Documentation/SubmittingPatches#L397 The use at line 401 by maintainers does not seem to me to be 'exclusive'. For instance, I've used Acked-by when someone else modifies a piece of code I've contributed (e.g. to fix a bug), to indicate I agree with them. It's also pretty clear (line 437 and 462) what Reviewed-by: means
Am 08.07.2013 16:10, schrieb Peter Maydell: > On 8 July 2013 15:04, Anthony Liguori <anthony@codemonkey.ws> wrote: >> (Just a nit and responding because this happens commonly). >> >> You probably mean Reviewed-by. Acked-by really means, "I am not the >> maintainer of this area, I have not reviewed this patch, but I am >> generally okay with the idea as best I can tell." > > Don't you mean "I *am* the maintainer of this area" ? I've always > assumed it means "as the maintainer I have a potential veto over > this code change and I am explicitly not exercising it even though > I may not have done a complete review and/or test"... I think Anthony was referring to: if I am the maintainer I don't usually put tags on patches but pick them up and add my Signed-off-by. (Possible exception: when only part of a series is good and you don't feel like cherry-picking from it.) Also we have an increasing number of series (CPUState, PCI, IOMMU) that touch things across the tree with more than one maintainer involved, where in my case I'm happy about getting Acked-bys at all. :) >> It's a very low vote of confidence. I wouldn't apply a patch that only >> had Acked-bys. >> >> OTOH, Reviewed-by means, "I have reviewed the patch and believe it works >> as described and meets project guidelines". Based on your review of V4, >> pretty sure that's what you mean here. >> >> https://github.com/torvalds/linux/blob/master/Documentation/SubmittingPatches#L392 >> >> The distinction matters in practice because I have scripts to track >> patches based on whether they've received Reviewed-bys or not. I'm >> often running into cases where people are Acked-by'ing instead of >> Reviewed-by'ing patches and then wondering why they haven't gotten >> merged... > > I think Andreas is the major exponent of the idea that "acked-by" > is stronger than "reviewed-by". Regardless, I think we should > standardise on what we mean by both tags. (Alas the kernel docs > are not entirely clear about acked-by, though the meaning of > reviewed-by is certainly clear.) Exponent? I am not advocating it's "stronger". However I believe that they do express different things - ack may express that the patch has been looked at and possibly tested but may contain stylistic or convention nits, whereas Reviewed-by says the code looks fine but is not guaranteed to build on the supported platforms. Adding a Reviewed-by on an obvious spelling fix so that it gets picked up already feels silly to me, and adding two tags (Reviewed-by+Tested-by or Acked-by+Reviewed-by+Tested-by) even more so. We could certainly use some clear guidance on the Wiki. Volunteers? Cheers, Andreas
Peter Maydell <peter.maydell@linaro.org> writes: > On 8 July 2013 15:04, Anthony Liguori <anthony@codemonkey.ws> wrote: >> (Just a nit and responding because this happens commonly). >> >> You probably mean Reviewed-by. Acked-by really means, "I am not the >> maintainer of this area, I have not reviewed this patch, but I am >> generally okay with the idea as best I can tell." > > Don't you mean "I *am* the maintainer of this area" ? No. It's "this looks okay to me". A maintainer would be expected to do a more thorough review than just a first pass "this looks okay to me." > I've always > assumed it means "as the maintainer I have a potential veto over > this code change and I am explicitly not exercising it even though > I may not have done a complete review and/or test"... "As *a* maintainer". It's basically, "my opinion here matters so I'm going to voice my approval." It's not limited to maintainers though. >> It's a very low vote of confidence. I wouldn't apply a patch that only >> had Acked-bys. >> >> OTOH, Reviewed-by means, "I have reviewed the patch and believe it works >> as described and meets project guidelines". Based on your review of V4, >> pretty sure that's what you mean here. >> >> https://github.com/torvalds/linux/blob/master/Documentation/SubmittingPatches#L392 >> >> The distinction matters in practice because I have scripts to track >> patches based on whether they've received Reviewed-bys or not. I'm >> often running into cases where people are Acked-by'ing instead of >> Reviewed-by'ing patches and then wondering why they haven't gotten >> merged... > > I think Andreas is the major exponent of the idea that "acked-by" > is stronger than "reviewed-by". Regardless, I think we should > standardise on what we mean by both tags. (Alas the kernel docs > are not entirely clear about acked-by, though the meaning of > reviewed-by is certainly clear.) That's why I referred to them. They seem clear to me. Suggestions for improvement are welcome of course :-) Regards, Anthony Liguori > > thanks > -- PMM
Andreas Färber <afaerber@suse.de> writes: > Am 08.07.2013 16:10, schrieb Peter Maydell: >> On 8 July 2013 15:04, Anthony Liguori <anthony@codemonkey.ws> wrote: >>> (Just a nit and responding because this happens commonly). >>> >>> You probably mean Reviewed-by. Acked-by really means, "I am not the >>> maintainer of this area, I have not reviewed this patch, but I am >>> generally okay with the idea as best I can tell." >> >> Don't you mean "I *am* the maintainer of this area" ? I've always >> assumed it means "as the maintainer I have a potential veto over >> this code change and I am explicitly not exercising it even though >> I may not have done a complete review and/or test"... > > I think Anthony was referring to: if I am the maintainer I don't usually > put tags on patches but pick them up and add my Signed-off-by. > (Possible exception: when only part of a series is good and you don't > feel like cherry-picking from it.) Right, it goes: 1) Acked-by: I haven't reviewed the code in detail but the general idea seems sane. 2) Reviewed-by: The general idea seems sane, and I have done a thorough review of the patch in question. 3) Signed-off-by: All of the above, plus I have ensured that the code is of good quality, does not break things, and the other things expected of a maintainer. This is considered to be a legally binding statement too based on the DCO so be aware of that and ensure you have the right approval to make such a statement. Semantics aside, let me be clear. If you want a patch to be merged, you need to do a Reviewed-by. Acked-by is not good enough to get something merged on its own. Regards, Anthony Liguori
On 8 July 2013 16:20, Anthony Liguori <anthony@codemonkey.ws> wrote: > Right, it goes: > > 1) Acked-by: > > I haven't reviewed the code in detail but the general idea seems sane. > > 2) Reviewed-by: > > The general idea seems sane, and I have done a thorough review of the > patch in question. > > 3) Signed-off-by: > > All of the above, plus I have ensured that the code is of good quality, > does not break things, and the other things expected of a maintainer. > This is considered to be a legally binding statement too based on the > DCO so be aware of that and ensure you have the right approval to make > such a statement. I agree with this and it matches my idea of what the semantics are. -- PMM
Am 08.07.2013 17:34, schrieb Peter Maydell: > On 8 July 2013 16:20, Anthony Liguori <anthony@codemonkey.ws> wrote: >> Right, it goes: >> >> 1) Acked-by: >> >> I haven't reviewed the code in detail but the general idea seems sane. >> >> 2) Reviewed-by: >> >> The general idea seems sane, and I have done a thorough review of the >> patch in question. >> >> 3) Signed-off-by: >> >> All of the above, plus I have ensured that the code is of good quality, >> does not break things, and the other things expected of a maintainer. >> This is considered to be a legally binding statement too based on the >> DCO so be aware of that and ensure you have the right approval to make >> such a statement. > > I agree with this and it matches my idea of what the semantics are. Matches my understanding, too. Andreas
On Mon, 8 Jul 2013, Anthony Liguori wrote: > Andreas Färber <afaerber@suse.de> writes: > > > Am 08.07.2013 16:10, schrieb Peter Maydell: > >> On 8 July 2013 15:04, Anthony Liguori <anthony@codemonkey.ws> wrote: > >>> (Just a nit and responding because this happens commonly). > >>> > >>> You probably mean Reviewed-by. Acked-by really means, "I am not the > >>> maintainer of this area, I have not reviewed this patch, but I am > >>> generally okay with the idea as best I can tell." > >> > >> Don't you mean "I *am* the maintainer of this area" ? I've always > >> assumed it means "as the maintainer I have a potential veto over > >> this code change and I am explicitly not exercising it even though > >> I may not have done a complete review and/or test"... > > > > I think Anthony was referring to: if I am the maintainer I don't usually > > put tags on patches but pick them up and add my Signed-off-by. > > (Possible exception: when only part of a series is good and you don't > > feel like cherry-picking from it.) > > Right, it goes: > > 1) Acked-by: > > I haven't reviewed the code in detail but the general idea seems sane. > > 2) Reviewed-by: > > The general idea seems sane, and I have done a thorough review of the > patch in question. > > 3) Signed-off-by: > > All of the above, plus I have ensured that the code is of good quality, > does not break things, and the other things expected of a maintainer. > This is considered to be a legally binding statement too based on the > DCO so be aware of that and ensure you have the right approval to make > such a statement. I don't think that is a good idea to mix up DCO with reviewing patches. In fact in the Linux community I think that it's pretty clear that Signed-off-by doesn't mean anything other than "at least a portion of the changes have been done by me and I am the Copyright owner of them". For example Alice writes a patch and goes away, Bob takes it, rewrites most of it and then sends it upstream. The patch has Alice and Bob Signed-off-by but Alice might not even read Bob's patch.
On Mon, 8 Jul 2013, Stefano Stabellini wrote: > On Mon, 8 Jul 2013, Anthony Liguori wrote: > > Andreas Färber <afaerber@suse.de> writes: > > > > > Am 08.07.2013 16:10, schrieb Peter Maydell: > > >> On 8 July 2013 15:04, Anthony Liguori <anthony@codemonkey.ws> wrote: > > >>> (Just a nit and responding because this happens commonly). > > >>> > > >>> You probably mean Reviewed-by. Acked-by really means, "I am not the > > >>> maintainer of this area, I have not reviewed this patch, but I am > > >>> generally okay with the idea as best I can tell." > > >> > > >> Don't you mean "I *am* the maintainer of this area" ? I've always > > >> assumed it means "as the maintainer I have a potential veto over > > >> this code change and I am explicitly not exercising it even though > > >> I may not have done a complete review and/or test"... > > > > > > I think Anthony was referring to: if I am the maintainer I don't usually > > > put tags on patches but pick them up and add my Signed-off-by. > > > (Possible exception: when only part of a series is good and you don't > > > feel like cherry-picking from it.) > > > > Right, it goes: > > > > 1) Acked-by: > > > > I haven't reviewed the code in detail but the general idea seems sane. > > > > 2) Reviewed-by: > > > > The general idea seems sane, and I have done a thorough review of the > > patch in question. > > > > 3) Signed-off-by: > > > > All of the above, plus I have ensured that the code is of good quality, > > does not break things, and the other things expected of a maintainer. > > This is considered to be a legally binding statement too based on the > > DCO so be aware of that and ensure you have the right approval to make > > such a statement. > > I don't think that is a good idea to mix up DCO with reviewing patches. > In fact in the Linux community I think that it's pretty clear that > Signed-off-by doesn't mean anything other than "at least a portion of > the changes have been done by me and I am the Copyright owner of them". > > For example Alice writes a patch and goes away, Bob takes it, rewrites > most of it and then sends it upstream. The patch has Alice and Bob > Signed-off-by but Alice might not even read Bob's patch. I forgot to add: Anybody that touch the patch adds his own Signed-off-by. Even applying a patch manually to a tree counts, that's why maintainers add Signed-off-by.
Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes: > On Mon, 8 Jul 2013, Anthony Liguori wrote: >> Andreas Färber <afaerber@suse.de> writes: >> >> Right, it goes: >> >> 1) Acked-by: >> >> I haven't reviewed the code in detail but the general idea seems sane. >> >> 2) Reviewed-by: >> >> The general idea seems sane, and I have done a thorough review of the >> patch in question. >> >> 3) Signed-off-by: >> >> All of the above, plus I have ensured that the code is of good quality, >> does not break things, and the other things expected of a maintainer. >> This is considered to be a legally binding statement too based on the >> DCO so be aware of that and ensure you have the right approval to make >> such a statement. > > I don't think that is a good idea to mix up DCO with reviewing > patches. It's all a question of patch origin and accounting. DCO is just one part of it. > In fact in the Linux community I think that it's pretty clear that > Signed-off-by doesn't mean anything other than "at least a portion of > the changes have been done by me and I am the Copyright owner of > them". No, it also means: "I can certify that the person who provided the patch to me has the appropriate rights to submit the patch." See section (c) of the DCO. It's about establishing a chain of custody. I'm not making any kind of judgement when I merge a pull request from you because you've told me (by adding your Signed-off-by) that all of the code is of appropriate origin. Of course, if you are not also saying that the code is of high quality and does what it's described too, I don't really care about the code origin in the first place :-) So this is an important part of it too. Anyone can add a Signed-off-by. There's no requirement on authorship. It's just not all that useful outside of a maintainership context. If you cherry pick someone's patch from the mailing list and add it to your series, you should add a Signed-off-by to it even though you aren't necessarily the maintainer of the area. > For example Alice writes a patch and goes away, Bob takes it, rewrites > most of it and then sends it upstream. The patch has Alice and Bob > Signed-off-by but Alice might not even read Bob's patch. The ordering of Signed-off-by has significance. In this case, Alice did not Signed-off-by Bob's changes and that's expressed in the ordering. Regards, Anthony Liguori
On Mon, 8 Jul 2013, Anthony Liguori wrote: > Stefano Stabellini <stefano.stabellini@eu.citrix.com> writes: > > > On Mon, 8 Jul 2013, Anthony Liguori wrote: > >> Andreas Färber <afaerber@suse.de> writes: > >> > >> Right, it goes: > >> > >> 1) Acked-by: > >> > >> I haven't reviewed the code in detail but the general idea seems sane. > >> > >> 2) Reviewed-by: > >> > >> The general idea seems sane, and I have done a thorough review of the > >> patch in question. > >> > >> 3) Signed-off-by: > >> > >> All of the above, plus I have ensured that the code is of good quality, > >> does not break things, and the other things expected of a maintainer. > >> This is considered to be a legally binding statement too based on the > >> DCO so be aware of that and ensure you have the right approval to make > >> such a statement. > > > > I don't think that is a good idea to mix up DCO with reviewing > > patches. > > It's all a question of patch origin and accounting. DCO is just one > part of it. > > > In fact in the Linux community I think that it's pretty clear that > > Signed-off-by doesn't mean anything other than "at least a portion of > > the changes have been done by me and I am the Copyright owner of > > them". > > No, it also means: "I can certify that the person who provided the patch > to me has the appropriate rights to submit the patch." See section (c) > of the DCO. > > It's about establishing a chain of custody. I'm not making any kind of > judgement when I merge a pull request from you because you've told me > (by adding your Signed-off-by) that all of the code is of appropriate > origin. Right, that's a much better way of saying it than what I wrote :) > Of course, if you are not also saying that the code is of high quality > and does what it's described too, I don't really care about the code > origin in the first place :-) So this is an important part of it too. I guess that's an implicit part of the agreement between you and the maintainers. I was just saying that given that Signed-off-by has already a clearly defined meaning related to DCO, I don't think is a good idea to overload it with other meanings related to the quality of the code.
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index 2017560..cd2df6a 100644 --- a/hw/xen/Makefile.objs +++ b/hw/xen/Makefile.objs @@ -1,5 +1,6 @@ # xen backend driver support common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o +common-obj-y += xen_pvdevice.o obj-$(CONFIG_XEN_I386) += xen_platform.o xen_apic.o obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o diff --git a/hw/xen/xen_pvdevice.c b/hw/xen/xen_pvdevice.c new file mode 100644 index 0000000..93dfab2 --- /dev/null +++ b/hw/xen/xen_pvdevice.c @@ -0,0 +1,131 @@ +/* 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" +#include "trace.h" + +#define TYPE_XEN_PV_DEVICE "xen-pvdevice" + +#define XEN_PV_DEVICE(obj) \ + OBJECT_CHECK(XenPVDevice, (obj), TYPE_XEN_PV_DEVICE) + +typedef struct XenPVDevice { + /*< private >*/ + PCIDevice parent_obj; + /*< public >*/ + uint16_t vendor_id; + uint16_t device_id; + uint8_t revision; + uint32_t size; + MemoryRegion mmio; +} XenPVDevice; + +static uint64_t xen_pv_mmio_read(void *opaque, hwaddr addr, + unsigned size) +{ + trace_xen_pv_mmio_read(addr); + + return ~(uint64_t)0; +} + +static void xen_pv_mmio_write(void *opaque, hwaddr addr, + uint64_t val, unsigned size) +{ + trace_xen_pv_mmio_write(addr); +} + +static const MemoryRegionOps xen_pv_mmio_ops = { + .read = &xen_pv_mmio_read, + .write = &xen_pv_mmio_write, + .endianness = DEVICE_LITTLE_ENDIAN, +}; + +static int xen_pv_init(PCIDevice *pci_dev) +{ + XenPVDevice *d = XEN_PV_DEVICE(pci_dev); + uint8_t *pci_conf; + + pci_conf = pci_dev->config; + + pci_set_word(pci_conf + PCI_VENDOR_ID, d->vendor_id); + pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, d->vendor_id); + pci_set_word(pci_conf + PCI_DEVICE_ID, d->device_id); + pci_set_word(pci_conf + PCI_SUBSYSTEM_ID, d->device_id); + pci_set_byte(pci_conf + PCI_REVISION_ID, d->revision); + + pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_MEMORY); + + pci_config_set_prog_interface(pci_conf, 0); + + pci_conf[PCI_INTERRUPT_PIN] = 1; + + memory_region_init_io(&d->mmio, &xen_pv_mmio_ops, d, + "mmio", d->size); + + pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_MEM_PREFETCH, + &d->mmio); + + return 0; +} + +static Property xen_pv_props[] = { + DEFINE_PROP_UINT16("vendor-id", XenPVDevice, vendor_id, PCI_VENDOR_ID_XEN), + DEFINE_PROP_UINT16("device-id", XenPVDevice, device_id, PCI_DEVICE_ID_XEN_PVDEVICE), + DEFINE_PROP_UINT8("revision", XenPVDevice, revision, 0x01), + DEFINE_PROP_UINT32("size", XenPVDevice, size, 0x400000), + DEFINE_PROP_END_OF_LIST() +}; + +static void xen_pv_class_init(ObjectClass *klass, void *data) +{ + DeviceClass *dc = DEVICE_CLASS(klass); + PCIDeviceClass *k = PCI_DEVICE_CLASS(klass); + + k->init = xen_pv_init; + k->class_id = PCI_CLASS_SYSTEM_OTHER; + dc->desc = "Xen PV Device"; + dc->props = xen_pv_props; +} + +static const TypeInfo xen_pv_type_info = { + .name = TYPE_XEN_PV_DEVICE, + .parent = TYPE_PCI_DEVICE, + .instance_size = sizeof(XenPVDevice), + .class_init = xen_pv_class_init, +}; + +static void xen_pv_register_types(void) +{ + type_register_static(&xen_pv_type_info); +} + +type_init(xen_pv_register_types) diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h index d8dc2f1..263bca3 100644 --- a/include/hw/pci/pci_ids.h +++ b/include/hw/pci/pci_ids.h @@ -142,8 +142,9 @@ #define PCI_DEVICE_ID_INTEL_Q35_MCH 0x29c0 -#define PCI_VENDOR_ID_XEN 0x5853 -#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 +#define PCI_VENDOR_ID_XEN 0x5853 +#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 +#define PCI_DEVICE_ID_XEN_PVDEVICE 0x0002 #define PCI_VENDOR_ID_NEC 0x1033 #define PCI_DEVICE_ID_NEC_UPD720200 0x0194 diff --git a/trace-events b/trace-events index c5f1ccb..0445853 100644 --- a/trace-events +++ b/trace-events @@ -1161,3 +1161,7 @@ kvm_run_exit(int cpu_index, uint32_t reason) "cpu_index %d, reason %d" # qom/object.c object_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" object_class_dynamic_cast_assert(const char *type, const char *target, const char *file, int line, const char *func) "%s->%s (%s:%d:%s)" + +# hw/xen/xen_pvdevice.c +xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space (address %"PRIx64")" +xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space (address %"PRIx64")"