On 2015/8/30 17:20, Michael S. Tsirkin wrote:
> This seems hackish - would it be better to create this region
> automatically within kvm? Suggestions are welcome.
>
> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
> ---
> hw/misc/pci-testdev.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/hw/misc/pci-testdev.c b/hw/misc/pci-testdev.c
> index 94141a3..55efc32 100644
> --- a/hw/misc/pci-testdev.c
> +++ b/hw/misc/pci-testdev.c
> @@ -21,6 +21,7 @@
> #include "hw/pci/pci.h"
> #include "qemu/event_notifier.h"
> #include "qemu/osdep.h"
> +#include <sys/mman.h>
>
> typedef struct PCITestDevHdr {
> uint8_t test;
> @@ -82,11 +83,13 @@ typedef struct PCITestDevState {
> PCIDevice parent_obj;
> /*< public >*/
>
> + MemoryRegion zeromr;
> MemoryRegion mmio;
> MemoryRegion mbar;
> MemoryRegion portio;
> IOTest *tests;
> int current;
> + void *zero;
> } PCITestDevState;
>
> #define TYPE_PCI_TEST_DEV "pci-testdev"
> @@ -242,6 +245,11 @@ static void pci_testdev_realize(PCIDevice *pci_dev, Error **errp)
> uint8_t *pci_conf;
> char *name;
> int r, i;
> + d->zero = mmap(NULL, IOTEST_MEMSIZE * 2, PROT_READ,
> + MAP_SHARED | MAP_ANONYMOUS, -1, 0);
> +
Do we need think about hotplugging pci-testdev ? If yes, then we should release some resources
when hot-unplug a pci-testdev device:
munmap(d->zero, ...)
memory_region_del_subregion(&d->mbar, &d->mmio)
...
Regards,
-Gonglei
> + memory_region_init_ram_ptr(&d->zeromr, OBJECT(d), "pci-testdev-zero", 0x1000, d->zero);
> + memory_region_set_readonly(&d->zeromr, true);
>
> pci_conf = pci_dev->config;
>
> @@ -286,6 +294,11 @@ static void pci_testdev_realize(PCIDevice *pci_dev, Error **errp)
> test->hasnotifier = false;
> continue;
> }
> +
> + if (test->hasnotifier && !test->size) {
> + memory_region_add_subregion_overlap(&d->mbar, le32_to_cpu(test->hdr->offset),
> + &d->zeromr, 2 /* prio */);
> + }
> r = event_notifier_init(&test->notifier, 0);
> assert(r >= 0);
> test->hasnotifier = true;
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
