Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Mon, Jan 07, 2019 at 03:28:36PM +, xuyandong wrote:
>
>
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: Monday, January 07, 2019 11:06 PM
> > To: xuyandong
> > Cc: mar...@redhat.com; Paolo Bonzini ; qemu-
> > de...@nongnu.org; Zhanghailiang ;
> > wangxin (U) ; Huangweidong (C)
> >
> > Subject: Re: [BUG]Unassigned mem write during pci device hot-plug
> >
> > On Mon, Jan 07, 2019 at 02:37:17PM +, xuyandong wrote:
> > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > In our test, we configured VM with several
> > > > > > > > > > > > > pci-bridges and a virtio-net nic been attached
> > > > > > > > > > > > > with bus 4,
> > > > > > > > > > > > >
> > > > > > > > > > > > > After VM is startup, We ping this nic from host to
> > > > > > > > > > > > > judge if it is working normally. Then, we hot add
> > > > > > > > > > > > > pci devices to this VM with bus
> > > > > > > > 0.
> > > > > > > > > > > > >
> > > > > > > > > > > > > We found the virtio-net NIC in bus 4 is not
> > > > > > > > > > > > > working (can not
> > > > > > > > > > > > > connect) occasionally, as it kick virtio backend
> > > > > > > > > > > > > failure with error
> > >
> > > > > > > But I have another question, if we only fix this problem in
> > > > > > > the kernel, the Linux version that has been released does not
> > > > > > > work well on the
> > > > > > virtualization platform.
> > > > > > > Is there a way to fix this problem in the backend?
> > >
> > > Hi Michael,
> > >
> > > If we want to fix this problem on the backend, it is not enough to
> > > consider only PCI device hot plugging, because I found that if we use
> > > a command like "echo 1 > /sys/bus/pci/rescan" in guest, this problem is
> > > very
> > easy to reproduce.
> > >
> > > From the perspective of device emulation, when guest writes 0x
> > > to the BAR, guest just want to get the size of the region but not really
> > updating the address space.
> > > So I made the following patch to avoid update pci mapping.
> > >
> > > Do you think this make sense?
> > >
> > > [PATCH] pci: avoid update pci mapping when writing 0x to BAR
> > >
> > > When guest writes 0x to the BAR, guest just want to get the
> > > size of the region but not really updating the address space.
> > > So when guest writes 0x to BAR, we need avoid
> > > pci_update_mappings or pci_bridge_update_mappings.
> > >
> > > Signed-off-by: xuyandong
> >
> > I see how that will address the common case however there are a bunch of
> > issues here. First of all it's easy to trigger the update by some other
> > action like
> > VM migration. More importantly it's just possible that guest actually does
> > want
> > to set the low 32 bit of the address to all ones. For example, that is
> > clearly
> > listed as a way to disable all devices behind the bridge in the pci to pci
> > bridge
> > spec.
>
> Ok, I see. If I only skip upate when guest writing 0x to Prefetcable
> Base Upper 32 Bits
> to meet the kernel double check problem.
> Do you think there is still risk?
Well it's non zero since spec says such a write should disable all
accesses. Just an idea: why not add an option to disable upper 32 bit?
That is ugly and limits space but spec compliant.
> >
> > Given upstream is dragging it's feet I'm open to adding a flag that will
> > help
> > keep guests going as a temporary measure.
> > We will need to think about ways to restrict this as much as we can.
> >
> >
> > > ---
> > > hw/pci/pci.c| 6 --
> > > hw/pci/pci_bridge.c | 8 +---
> > > 2 files changed, 9 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 56b13b3..ef368e1 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -1361,6 +1361,7 @@ void pci_default_write_config(PCIDevice *d,
> > > uint32_t addr, uint32_t val_in, int {
> > > int i, was_irq_disabled = pci_irq_disabled(d);
> > > uint32_t val = val_in;
> > > +uint64_t barmask = (1 << l*8) - 1;
> > >
> > > for (i = 0; i < l; val >>= 8, ++i) {
> > > uint8_t wmask = d->wmask[addr + i]; @@ -1369,9 +1370,10 @@
> > > void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t
> > > val_in,
> > int
> > > d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
> > > wmask);
> > > d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to
> > > Clear */
> > > }
> > > -if (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> > > +if ((val_in != barmask &&
> > > + (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> > > ranges_overlap(addr, l, PCI_ROM_ADDRESS, 4) ||
> > > -ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4) ||
> > > +ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4))) ||
> > > range_covers_byte(addr, l, PCI_COMMAND))
> > >
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Monday, January 07, 2019 11:06 PM
> To: xuyandong
> Cc: mar...@redhat.com; Paolo Bonzini ; qemu-
> de...@nongnu.org; Zhanghailiang ;
> wangxin (U) ; Huangweidong (C)
>
> Subject: Re: [BUG]Unassigned mem write during pci device hot-plug
>
> On Mon, Jan 07, 2019 at 02:37:17PM +, xuyandong wrote:
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > In our test, we configured VM with several
> > > > > > > > > > > > pci-bridges and a virtio-net nic been attached
> > > > > > > > > > > > with bus 4,
> > > > > > > > > > > >
> > > > > > > > > > > > After VM is startup, We ping this nic from host to
> > > > > > > > > > > > judge if it is working normally. Then, we hot add
> > > > > > > > > > > > pci devices to this VM with bus
> > > > > > > 0.
> > > > > > > > > > > >
> > > > > > > > > > > > We found the virtio-net NIC in bus 4 is not
> > > > > > > > > > > > working (can not
> > > > > > > > > > > > connect) occasionally, as it kick virtio backend
> > > > > > > > > > > > failure with error
> >
> > > > > > But I have another question, if we only fix this problem in
> > > > > > the kernel, the Linux version that has been released does not
> > > > > > work well on the
> > > > > virtualization platform.
> > > > > > Is there a way to fix this problem in the backend?
> >
> > Hi Michael,
> >
> > If we want to fix this problem on the backend, it is not enough to
> > consider only PCI device hot plugging, because I found that if we use
> > a command like "echo 1 > /sys/bus/pci/rescan" in guest, this problem is very
> easy to reproduce.
> >
> > From the perspective of device emulation, when guest writes 0x
> > to the BAR, guest just want to get the size of the region but not really
> updating the address space.
> > So I made the following patch to avoid update pci mapping.
> >
> > Do you think this make sense?
> >
> > [PATCH] pci: avoid update pci mapping when writing 0x to BAR
> >
> > When guest writes 0x to the BAR, guest just want to get the
> > size of the region but not really updating the address space.
> > So when guest writes 0x to BAR, we need avoid
> > pci_update_mappings or pci_bridge_update_mappings.
> >
> > Signed-off-by: xuyandong
>
> I see how that will address the common case however there are a bunch of
> issues here. First of all it's easy to trigger the update by some other
> action like
> VM migration. More importantly it's just possible that guest actually does
> want
> to set the low 32 bit of the address to all ones. For example, that is
> clearly
> listed as a way to disable all devices behind the bridge in the pci to pci
> bridge
> spec.
Ok, I see. If I only skip upate when guest writing 0x to Prefetcable
Base Upper 32 Bits
to meet the kernel double check problem.
Do you think there is still risk?
>
> Given upstream is dragging it's feet I'm open to adding a flag that will help
> keep guests going as a temporary measure.
> We will need to think about ways to restrict this as much as we can.
>
>
> > ---
> > hw/pci/pci.c| 6 --
> > hw/pci/pci_bridge.c | 8 +---
> > 2 files changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 56b13b3..ef368e1 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -1361,6 +1361,7 @@ void pci_default_write_config(PCIDevice *d,
> > uint32_t addr, uint32_t val_in, int {
> > int i, was_irq_disabled = pci_irq_disabled(d);
> > uint32_t val = val_in;
> > +uint64_t barmask = (1 << l*8) - 1;
> >
> > for (i = 0; i < l; val >>= 8, ++i) {
> > uint8_t wmask = d->wmask[addr + i]; @@ -1369,9 +1370,10 @@
> > void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val_in,
> int
> > d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
> > wmask);
> > d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear
> > */
> > }
> > -if (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> > +if ((val_in != barmask &&
> > + (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> > ranges_overlap(addr, l, PCI_ROM_ADDRESS, 4) ||
> > -ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4) ||
> > +ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4))) ||
> > range_covers_byte(addr, l, PCI_COMMAND))
> > pci_update_mappings(d);
> >
> > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c index
> > ee9dff2..f2bad79 100644
> > --- a/hw/pci/pci_bridge.c
> > +++ b/hw/pci/pci_bridge.c
> > @@ -253,17 +253,19 @@ void pci_bridge_write_config(PCIDevice *d,
> > PCIBridge *s = PCI_BRIDGE(d);
> > uint16_t oldctl = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
> > uint16_t newctl;
> > +uint64_t barmask = (1 << len * 8) - 1;
> >
> > pci_default_write_config(d, address, val, len);
> >
> >
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Mon, Jan 07, 2019 at 02:37:17PM +, xuyandong wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > In our test, we configured VM with several pci-bridges
> > > > > > > > > > > and a virtio-net nic been attached with bus 4,
> > > > > > > > > > >
> > > > > > > > > > > After VM is startup, We ping this nic from host to
> > > > > > > > > > > judge if it is working normally. Then, we hot add pci
> > > > > > > > > > > devices to this VM with bus
> > > > > > 0.
> > > > > > > > > > >
> > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working
> > > > > > > > > > > (can not
> > > > > > > > > > > connect) occasionally, as it kick virtio backend
> > > > > > > > > > > failure with error
>
> > > > > But I have another question, if we only fix this problem in the
> > > > > kernel, the Linux version that has been released does not work
> > > > > well on the
> > > > virtualization platform.
> > > > > Is there a way to fix this problem in the backend?
> > > >
> > > > There could we a way to work around this.
> > > > Does below help?
> > >
> > > I am sorry to tell you, I tested this patch and it doesn't work fine.
> > >
> > > >
> > > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > > > 236a20eaa8..7834cac4b0 100644
> > > > --- a/hw/i386/acpi-build.c
> > > > +++ b/hw/i386/acpi-build.c
> > > > @@ -551,7 +551,7 @@ static void build_append_pci_bus_devices(Aml
> > > > *parent_scope, PCIBus *bus,
> > > >
> > > > aml_append(method, aml_store(aml_int(bsel_val),
> > aml_name("BNUM")));
> > > > aml_append(method,
> > > > -aml_call2("DVNT", aml_name("PCIU"), aml_int(1) /* Device
> > > > Check
> > */)
> > > > +aml_call2("DVNT", aml_name("PCIU"), aml_int(4) /*
> > > > + Device Check Light */)
> > > > );
> > > > aml_append(method,
> > > > aml_call2("DVNT", aml_name("PCID"), aml_int(3)/* Eject
> > > > Request */)
> >
> >
> > Oh I see, another bug:
> >
> > case ACPI_NOTIFY_DEVICE_CHECK_LIGHT:
> > acpi_handle_debug(handle, "ACPI_NOTIFY_DEVICE_CHECK_LIGHT
> > event\n");
> > /* TBD: Exactly what does 'light' mean? */
> > break;
> >
> > And then e.g. acpi_generic_hotplug_event(struct acpi_device *adev, u32 type)
> > and friends all just ignore this event type.
> >
> >
> >
> > --
> > MST
>
> Hi Michael,
>
> If we want to fix this problem on the backend, it is not enough to consider
> only PCI
> device hot plugging, because I found that if we use a command like
> "echo 1 > /sys/bus/pci/rescan" in guest, this problem is very easy to
> reproduce.
>
> From the perspective of device emulation, when guest writes 0x to the
> BAR,
> guest just want to get the size of the region but not really updating the
> address space.
> So I made the following patch to avoid update pci mapping.
>
> Do you think this make sense?
>
> [PATCH] pci: avoid update pci mapping when writing 0x to BAR
>
> When guest writes 0x to the BAR, guest just want to get the size of
> the region
> but not really updating the address space.
> So when guest writes 0x to BAR, we need avoid pci_update_mappings
> or pci_bridge_update_mappings.
>
> Signed-off-by: xuyandong
I see how that will address the common case however there are a bunch of
issues here. First of all it's easy to trigger the update by some other
action like VM migration. More importantly it's just possible that
guest actually does want to set the low 32 bit of the address to all
ones. For example, that is clearly listed as a way to disable all
devices behind the bridge in the pci to pci bridge spec.
Given upstream is dragging it's feet I'm open to adding a flag
that will help keep guests going as a temporary measure.
We will need to think about ways to restrict this as much as
we can.
> ---
> hw/pci/pci.c| 6 --
> hw/pci/pci_bridge.c | 8 +---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 56b13b3..ef368e1 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1361,6 +1361,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t
> addr, uint32_t val_in, int
> {
> int i, was_irq_disabled = pci_irq_disabled(d);
> uint32_t val = val_in;
> +uint64_t barmask = (1 << l*8) - 1;
>
> for (i = 0; i < l; val >>= 8, ++i) {
> uint8_t wmask = d->wmask[addr + i];
> @@ -1369,9 +1370,10 @@ void pci_default_write_config(PCIDevice *d, uint32_t
> addr, uint32_t val_in, int
> d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
> d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear */
> }
> -if (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> +if ((val_in != barmask &&
> + (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> ranges_overlap(addr, l,
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
> -Original Message-
> From: xuyandong
> Sent: Monday, January 07, 2019 10:37 PM
> To: 'Michael S. Tsirkin'
> Cc: mar...@redhat.com; Paolo Bonzini ; qemu-
> de...@nongnu.org; Zhanghailiang ;
> wangxin (U) ; Huangweidong (C)
>
> Subject: RE: [BUG]Unassigned mem write during pci device hot-plug
>
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > In our test, we configured VM with several
> > > > > > > > > > > pci-bridges and a virtio-net nic been attached with
> > > > > > > > > > > bus 4,
> > > > > > > > > > >
> > > > > > > > > > > After VM is startup, We ping this nic from host to
> > > > > > > > > > > judge if it is working normally. Then, we hot add
> > > > > > > > > > > pci devices to this VM with bus
> > > > > > 0.
> > > > > > > > > > >
> > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working
> > > > > > > > > > > (can not
> > > > > > > > > > > connect) occasionally, as it kick virtio backend
> > > > > > > > > > > failure with error
>
> > > > > But I have another question, if we only fix this problem in the
> > > > > kernel, the Linux version that has been released does not work
> > > > > well on the
> > > > virtualization platform.
> > > > > Is there a way to fix this problem in the backend?
> > > >
> > > > There could we a way to work around this.
> > > > Does below help?
> > >
> > > I am sorry to tell you, I tested this patch and it doesn't work fine.
> > >
> > > >
> > > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > > > 236a20eaa8..7834cac4b0 100644
> > > > --- a/hw/i386/acpi-build.c
> > > > +++ b/hw/i386/acpi-build.c
> > > > @@ -551,7 +551,7 @@ static void build_append_pci_bus_devices(Aml
> > > > *parent_scope, PCIBus *bus,
> > > >
> > > > aml_append(method, aml_store(aml_int(bsel_val),
> > aml_name("BNUM")));
> > > > aml_append(method,
> > > > -aml_call2("DVNT", aml_name("PCIU"), aml_int(1) /* Device
> Check
> > */)
> > > > +aml_call2("DVNT", aml_name("PCIU"), aml_int(4) /*
> > > > + Device Check Light */)
> > > > );
> > > > aml_append(method,
> > > > aml_call2("DVNT", aml_name("PCID"), aml_int(3)/*
> > > > Eject Request */)
> >
> >
> > Oh I see, another bug:
> >
> > case ACPI_NOTIFY_DEVICE_CHECK_LIGHT:
> > acpi_handle_debug(handle,
> > "ACPI_NOTIFY_DEVICE_CHECK_LIGHT event\n");
> > /* TBD: Exactly what does 'light' mean? */
> > break;
> >
> > And then e.g. acpi_generic_hotplug_event(struct acpi_device *adev, u32
> > type) and friends all just ignore this event type.
> >
> >
> >
> > --
> > MST
>
> Hi Michael,
>
> If we want to fix this problem on the backend, it is not enough to consider
> only
> PCI device hot plugging, because I found that if we use a command like "echo
> 1 >
> /sys/bus/pci/rescan" in guest, this problem is very easy to reproduce.
>
> From the perspective of device emulation, when guest writes 0x to the
> BAR, guest just want to get the size of the region but not really updating the
> address space.
> So I made the following patch to avoid update pci mapping.
>
> Do you think this make sense?
>
> [PATCH] pci: avoid update pci mapping when writing 0x to BAR
>
> When guest writes 0x to the BAR, guest just want to get the size of
> the
> region but not really updating the address space.
> So when guest writes 0x to BAR, we need avoid pci_update_mappings or
> pci_bridge_update_mappings.
>
> Signed-off-by: xuyandong
> ---
> hw/pci/pci.c| 6 --
> hw/pci/pci_bridge.c | 8 +---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 56b13b3..ef368e1 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1361,6 +1361,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t
> addr, uint32_t val_in, int {
> int i, was_irq_disabled = pci_irq_disabled(d);
> uint32_t val = val_in;
> +uint64_t barmask = (1 << l*8) - 1;
>
> for (i = 0; i < l; val >>= 8, ++i) {
> uint8_t wmask = d->wmask[addr + i]; @@ -1369,9 +1370,10 @@ void
> pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val_in, int
> d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
> d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear */
> }
> -if (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> +if ((val_in != barmask &&
> + (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
> ranges_overlap(addr, l, PCI_ROM_ADDRESS, 4) ||
> -ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4) ||
> +ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4))) ||
> range_covers_byte(addr, l, PCI_COMMAND))
> pci_update_mappings(d);
>
> diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c index ee9dff2..f2bad79
> 100644
> --- a/hw/pci/pci_bridge.c
> +++
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > In our test, we configured VM with several pci-bridges
> > > > > > > > > > and a virtio-net nic been attached with bus 4,
> > > > > > > > > >
> > > > > > > > > > After VM is startup, We ping this nic from host to
> > > > > > > > > > judge if it is working normally. Then, we hot add pci
> > > > > > > > > > devices to this VM with bus
> > > > > 0.
> > > > > > > > > >
> > > > > > > > > > We found the virtio-net NIC in bus 4 is not working
> > > > > > > > > > (can not
> > > > > > > > > > connect) occasionally, as it kick virtio backend
> > > > > > > > > > failure with error
> > > > But I have another question, if we only fix this problem in the
> > > > kernel, the Linux version that has been released does not work
> > > > well on the
> > > virtualization platform.
> > > > Is there a way to fix this problem in the backend?
> > >
> > > There could we a way to work around this.
> > > Does below help?
> >
> > I am sorry to tell you, I tested this patch and it doesn't work fine.
> >
> > >
> > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > > 236a20eaa8..7834cac4b0 100644
> > > --- a/hw/i386/acpi-build.c
> > > +++ b/hw/i386/acpi-build.c
> > > @@ -551,7 +551,7 @@ static void build_append_pci_bus_devices(Aml
> > > *parent_scope, PCIBus *bus,
> > >
> > > aml_append(method, aml_store(aml_int(bsel_val),
> aml_name("BNUM")));
> > > aml_append(method,
> > > -aml_call2("DVNT", aml_name("PCIU"), aml_int(1) /* Device
> > > Check
> */)
> > > +aml_call2("DVNT", aml_name("PCIU"), aml_int(4) /*
> > > + Device Check Light */)
> > > );
> > > aml_append(method,
> > > aml_call2("DVNT", aml_name("PCID"), aml_int(3)/* Eject
> > > Request */)
>
>
> Oh I see, another bug:
>
> case ACPI_NOTIFY_DEVICE_CHECK_LIGHT:
> acpi_handle_debug(handle, "ACPI_NOTIFY_DEVICE_CHECK_LIGHT
> event\n");
> /* TBD: Exactly what does 'light' mean? */
> break;
>
> And then e.g. acpi_generic_hotplug_event(struct acpi_device *adev, u32 type)
> and friends all just ignore this event type.
>
>
>
> --
> MST
Hi Michael,
If we want to fix this problem on the backend, it is not enough to consider
only PCI
device hot plugging, because I found that if we use a command like
"echo 1 > /sys/bus/pci/rescan" in guest, this problem is very easy to reproduce.
From the perspective of device emulation, when guest writes 0x to the
BAR,
guest just want to get the size of the region but not really updating the
address space.
So I made the following patch to avoid update pci mapping.
Do you think this make sense?
[PATCH] pci: avoid update pci mapping when writing 0x to BAR
When guest writes 0x to the BAR, guest just want to get the size of the
region
but not really updating the address space.
So when guest writes 0x to BAR, we need avoid pci_update_mappings
or pci_bridge_update_mappings.
Signed-off-by: xuyandong
---
hw/pci/pci.c| 6 --
hw/pci/pci_bridge.c | 8 +---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 56b13b3..ef368e1 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1361,6 +1361,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t
addr, uint32_t val_in, int
{
int i, was_irq_disabled = pci_irq_disabled(d);
uint32_t val = val_in;
+uint64_t barmask = (1 << l*8) - 1;
for (i = 0; i < l; val >>= 8, ++i) {
uint8_t wmask = d->wmask[addr + i];
@@ -1369,9 +1370,10 @@ void pci_default_write_config(PCIDevice *d, uint32_t
addr, uint32_t val_in, int
d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear */
}
-if (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
+if ((val_in != barmask &&
+ (ranges_overlap(addr, l, PCI_BASE_ADDRESS_0, 24) ||
ranges_overlap(addr, l, PCI_ROM_ADDRESS, 4) ||
-ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4) ||
+ranges_overlap(addr, l, PCI_ROM_ADDRESS1, 4))) ||
range_covers_byte(addr, l, PCI_COMMAND))
pci_update_mappings(d);
diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c
index ee9dff2..f2bad79 100644
--- a/hw/pci/pci_bridge.c
+++ b/hw/pci/pci_bridge.c
@@ -253,17 +253,19 @@ void pci_bridge_write_config(PCIDevice *d,
PCIBridge *s = PCI_BRIDGE(d);
uint16_t oldctl = pci_get_word(d->config + PCI_BRIDGE_CONTROL);
uint16_t newctl;
+uint64_t barmask = (1 << len * 8) - 1;
pci_default_write_config(d, address, val, len);
if (ranges_overlap(address, len, PCI_COMMAND, 2) ||
-/* io base/limit */
-ranges_overlap(address, len, PCI_IO_BASE, 2) ||
+(val != barmask &&
+ /* io base/limit */
+(ranges_overlap(address, len,
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Tue, Dec 11, 2018 at 03:51:09AM +, xuyandong wrote: > > On Tue, Dec 11, 2018 at 02:55:43AM +, xuyandong wrote: > > > On Tue, Dec 11, 2018 at 01:47:37AM +, xuyandong wrote: > > > > > On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and > > > > > > > > > a virtio-net nic been attached with bus 4, > > > > > > > > > > > > > > > > > > After VM is startup, We ping this nic from host to judge > > > > > > > > > if it is working normally. Then, we hot add pci devices to > > > > > > > > > this VM with bus > > > > 0. > > > > > > > > > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working (can > > > > > > > > > not > > > > > > > > > connect) occasionally, as it kick virtio backend failure with > > > > > > > > > error > > below: > > > > > > > > > > > > > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > > > > > > > > > > > > > - (prio 0, RW): > > > > > > > > > pci_bridge_pci > > > > > > > > > > > > > > > > > > fc80-fc803fff (prio 1, RW): > > > > > > > > > virtio-pci > > > > > > > > > > > > > > > > > > fc80-fc800fff (prio 0, RW): > > > > > > > > > virtio-pci-common > > > > > > > > > > > > > > > > > > fc801000-fc801fff (prio 0, RW): > > > > > > > > > virtio-pci-isr > > > > > > > > > > > > > > > > > > fc802000-fc802fff (prio 0, RW): > > > > > > > > > virtio-pci-device > > > > > > > > > > > > > > > > > > fc803000-fc803fff (prio 0, RW): > > > > > > > > > virtio-pci-notify <- io mem unassigned > > > > > > > > > > > > > > > > > > … > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We caught an exceptional address changing while this > > > > > > > > > problem happened, show as > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > Before pci_bridge_update_mappings： > > > > > > > > > > > > > > > > > > fc00-fc1f (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fc00-fc1f > > > > > > > > > > > > > > > > > > fc20-fc3f (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fc20-fc3f > > > > > > > > > > > > > > > > > > fc40-fc5f (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fc40-fc5f > > > > > > > > > > > > > > > > > > fc60-fc7f (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fc60-fc7f > > > > > > > > > > > > > > > > > > fc80-fc9f (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fc80-fc9f > > > > > > > > > <- correct Adress Spce > > > > > > > > > > > > > > > > > > fca0-fcbf (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fca0-fcbf > > > > > > > > > > > > > > > > > > fcc0-fcdf (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fcc0-fcdf > > > > > > > > > > > > > > > > > > fce0-fcff (prio 1, RW): > > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > > fce0-fcff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > > > > > > > > > > > > > fda0-fdbf (prio 1, RW): > > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > > fda0-fdbf > > > > > > > > > > > > > > > > > > fdc0-fddf (prio 1, RW): > > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > > fdc0-fddf > > > > > > > > > > > > > > > > > > fde0-fdff (prio 1, RW): > > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > > fde0-fdff > > > > > > > > > > > > > > > > > > fe00-fe1f (prio 1, RW): > > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > > fe00-fe1f > > > > > > > > > > > > > > > > > > fe20-fe3f (prio 1, RW): > > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > > fe20-fe3f > > > > > > > > > > > > > > > > > >
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Tue, Dec 11, 2018 at 03:51:09AM +, xuyandong wrote:
> > There could we a way to work around this.
> > Does below help?
>
> I am sorry to tell you, I tested this patch and it doesn't work fine.
What happens?
> >
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > 236a20eaa8..7834cac4b0 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -551,7 +551,7 @@ static void build_append_pci_bus_devices(Aml
> > *parent_scope, PCIBus *bus,
> >
> > aml_append(method, aml_store(aml_int(bsel_val), aml_name("BNUM")));
> > aml_append(method,
> > -aml_call2("DVNT", aml_name("PCIU"), aml_int(1) /* Device Check
> > */)
> > +aml_call2("DVNT", aml_name("PCIU"), aml_int(4) /* Device
> > + Check Light */)
> > );
> > aml_append(method,
> > aml_call2("DVNT", aml_name("PCID"), aml_int(3)/* Eject Request
> > */)
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
> On Tue, Dec 11, 2018 at 02:55:43AM +, xuyandong wrote: > > On Tue, Dec 11, 2018 at 01:47:37AM +, xuyandong wrote: > > > > On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and > > > > > > > > a virtio-net nic been attached with bus 4, > > > > > > > > > > > > > > > > After VM is startup, We ping this nic from host to judge > > > > > > > > if it is working normally. Then, we hot add pci devices to > > > > > > > > this VM with bus > > > 0. > > > > > > > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working (can > > > > > > > > not > > > > > > > > connect) occasionally, as it kick virtio backend failure with > > > > > > > > error > below: > > > > > > > > > > > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > > > > > > > > > > > - (prio 0, RW): > > > > > > > > pci_bridge_pci > > > > > > > > > > > > > > > > fc80-fc803fff (prio 1, RW): > > > > > > > > virtio-pci > > > > > > > > > > > > > > > > fc80-fc800fff (prio 0, RW): > > > > > > > > virtio-pci-common > > > > > > > > > > > > > > > > fc801000-fc801fff (prio 0, RW): > > > > > > > > virtio-pci-isr > > > > > > > > > > > > > > > > fc802000-fc802fff (prio 0, RW): > > > > > > > > virtio-pci-device > > > > > > > > > > > > > > > > fc803000-fc803fff (prio 0, RW): > > > > > > > > virtio-pci-notify <- io mem unassigned > > > > > > > > > > > > > > > > … > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We caught an exceptional address changing while this > > > > > > > > problem happened, show as > > > > > > > > follow: > > > > > > > > > > > > > > > > Before pci_bridge_update_mappings： > > > > > > > > > > > > > > > > fc00-fc1f (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fc00-fc1f > > > > > > > > > > > > > > > > fc20-fc3f (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fc20-fc3f > > > > > > > > > > > > > > > > fc40-fc5f (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fc40-fc5f > > > > > > > > > > > > > > > > fc60-fc7f (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fc60-fc7f > > > > > > > > > > > > > > > > fc80-fc9f (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fc80-fc9f > > > > > > > > <- correct Adress Spce > > > > > > > > > > > > > > > > fca0-fcbf (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fca0-fcbf > > > > > > > > > > > > > > > > fcc0-fcdf (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fcc0-fcdf > > > > > > > > > > > > > > > > fce0-fcff (prio 1, RW): > > > > > > > > alias pci_bridge_pref_mem @pci_bridge_pci > > > > > > > > fce0-fcff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > > > > > > > > > > > fda0-fdbf (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > fda0-fdbf > > > > > > > > > > > > > > > > fdc0-fddf (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > fdc0-fddf > > > > > > > > > > > > > > > > fde0-fdff (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > fde0-fdff > > > > > > > > > > > > > > > > fe00-fe1f (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > fe00-fe1f > > > > > > > > > > > > > > > > fe20-fe3f (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > fe20-fe3f > > > > > > > > > > > > > > > > fe40-fe5f (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > > fe40-fe5f > > > > > > > > > > > > > > > > fe60-fe7f (prio 1, RW): > > > > > > > > alias pci_bridge_mem @pci_bridge_pci > > > > > > > >
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Tue, Dec 11, 2018 at 02:55:43AM +, xuyandong wrote: > On Tue, Dec 11, 2018 at 01:47:37AM +, xuyandong wrote: > > > On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and a > > > > > > > virtio-net nic been attached with bus 4, > > > > > > > > > > > > > > After VM is startup, We ping this nic from host to judge if it > > > > > > > is working normally. Then, we hot add pci devices to this VM with > > > > > > > bus > > 0. > > > > > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working (can not > > > > > > > connect) occasionally, as it kick virtio backend failure with > > > > > > > error below: > > > > > > > > > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > > > > > > > > > - (prio 0, RW): > > > > > > > pci_bridge_pci > > > > > > > > > > > > > > fc80-fc803fff (prio 1, RW): virtio-pci > > > > > > > > > > > > > > fc80-fc800fff (prio 0, RW): > > > > > > > virtio-pci-common > > > > > > > > > > > > > > fc801000-fc801fff (prio 0, RW): > > > > > > > virtio-pci-isr > > > > > > > > > > > > > > fc802000-fc802fff (prio 0, RW): > > > > > > > virtio-pci-device > > > > > > > > > > > > > > fc803000-fc803fff (prio 0, RW): > > > > > > > virtio-pci-notify <- io mem unassigned > > > > > > > > > > > > > > … > > > > > > > > > > > > > > > > > > > > > > > > > > > > We caught an exceptional address changing while this problem > > > > > > > happened, show as > > > > > > > follow: > > > > > > > > > > > > > > Before pci_bridge_update_mappings： > > > > > > > > > > > > > > fc00-fc1f (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fc00-fc1f > > > > > > > > > > > > > > fc20-fc3f (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fc20-fc3f > > > > > > > > > > > > > > fc40-fc5f (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fc40-fc5f > > > > > > > > > > > > > > fc60-fc7f (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fc60-fc7f > > > > > > > > > > > > > > fc80-fc9f (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fc80-fc9f > > > > > > > <- correct Adress Spce > > > > > > > > > > > > > > fca0-fcbf (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fca0-fcbf > > > > > > > > > > > > > > fcc0-fcdf (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fcc0-fcdf > > > > > > > > > > > > > > fce0-fcff (prio 1, RW): alias > > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > > fce0-fcff > > > > > > > > > > > > > > > > > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > > > > > > > > > fda0-fdbf (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fda0-fdbf > > > > > > > > > > > > > > fdc0-fddf (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fdc0-fddf > > > > > > > > > > > > > > fde0-fdff (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fde0-fdff > > > > > > > > > > > > > > fe00-fe1f (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fe00-fe1f > > > > > > > > > > > > > > fe20-fe3f (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fe20-fe3f > > > > > > > > > > > > > > fe40-fe5f (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fe40-fe5f > > > > > > > > > > > > > > fe60-fe7f (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fe60-fe7f > > > > > > > > > > > > > > fe80-fe9f (prio 1, RW): alias > > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > > fe80-fe9f > > > > > > > > > > > > > >
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Tue, Dec 11, 2018 at 01:47:37AM +, xuyandong wrote: > > On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and a > > > > > > virtio-net nic been attached with bus 4, > > > > > > > > > > > > After VM is startup, We ping this nic from host to judge if it > > > > > > is working normally. Then, we hot add pci devices to this VM with > > > > > > bus > 0. > > > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working (can not > > > > > > connect) occasionally, as it kick virtio backend failure with error > > > > > > below: > > > > > > > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > > > > > > > - (prio 0, RW): > > > > > > pci_bridge_pci > > > > > > > > > > > > fc80-fc803fff (prio 1, RW): virtio-pci > > > > > > > > > > > > fc80-fc800fff (prio 0, RW): > > > > > > virtio-pci-common > > > > > > > > > > > > fc801000-fc801fff (prio 0, RW): > > > > > > virtio-pci-isr > > > > > > > > > > > > fc802000-fc802fff (prio 0, RW): > > > > > > virtio-pci-device > > > > > > > > > > > > fc803000-fc803fff (prio 0, RW): > > > > > > virtio-pci-notify <- io mem unassigned > > > > > > > > > > > > … > > > > > > > > > > > > > > > > > > > > > > > > We caught an exceptional address changing while this problem > > > > > > happened, show as > > > > > > follow: > > > > > > > > > > > > Before pci_bridge_update_mappings： > > > > > > > > > > > > fc00-fc1f (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fc00-fc1f > > > > > > > > > > > > fc20-fc3f (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fc20-fc3f > > > > > > > > > > > > fc40-fc5f (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fc40-fc5f > > > > > > > > > > > > fc60-fc7f (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fc60-fc7f > > > > > > > > > > > > fc80-fc9f (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fc80-fc9f > > > > > > <- correct Adress Spce > > > > > > > > > > > > fca0-fcbf (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fca0-fcbf > > > > > > > > > > > > fcc0-fcdf (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fcc0-fcdf > > > > > > > > > > > > fce0-fcff (prio 1, RW): alias > > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > > fce0-fcff > > > > > > > > > > > > > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > > > > > > > fda0-fdbf (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fda0-fdbf > > > > > > > > > > > > fdc0-fddf (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fdc0-fddf > > > > > > > > > > > > fde0-fdff (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fde0-fdff > > > > > > > > > > > > fe00-fe1f (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fe00-fe1f > > > > > > > > > > > > fe20-fe3f (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fe20-fe3f > > > > > > > > > > > > fe40-fe5f (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fe40-fe5f > > > > > > > > > > > > fe60-fe7f (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fe60-fe7f > > > > > > > > > > > > fe80-fe9f (prio 1, RW): alias > > > > > > pci_bridge_mem @pci_bridge_pci > > > > > > fe80-fe9f > > > > > > > > > > > > fc80-fc80 (prio 1, RW): alias > > > pci_bridge_pref_mem > > > > > > @pci_bridge_pci fc80-fc80 <- Exceptional > Adress > > > > > Space > > > > > > > > > > This one is empty though right? > > > > > > > > > > > > > > > > > > > > > > > We have figured out why this address becomes
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Tue, Dec 11, 2018 at 01:47:37AM +, xuyandong wrote: > On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and a > > > > > virtio-net nic been attached with bus 4, > > > > > > > > > > After VM is startup, We ping this nic from host to judge if it is > > > > > working normally. Then, we hot add pci devices to this VM with bus 0. > > > > > > > > > > We found the virtio-net NIC in bus 4 is not working (can not > > > > > connect) occasionally, as it kick virtio backend failure with error > > > > > below: > > > > > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > > > > > - (prio 0, RW): pci_bridge_pci > > > > > > > > > > fc80-fc803fff (prio 1, RW): virtio-pci > > > > > > > > > > fc80-fc800fff (prio 0, RW): > > > > > virtio-pci-common > > > > > > > > > > fc801000-fc801fff (prio 0, RW): > > > > > virtio-pci-isr > > > > > > > > > > fc802000-fc802fff (prio 0, RW): > > > > > virtio-pci-device > > > > > > > > > > fc803000-fc803fff (prio 0, RW): > > > > > virtio-pci-notify <- io mem unassigned > > > > > > > > > > … > > > > > > > > > > > > > > > > > > > > We caught an exceptional address changing while this problem > > > > > happened, show as > > > > > follow: > > > > > > > > > > Before pci_bridge_update_mappings： > > > > > > > > > > fc00-fc1f (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fc00-fc1f > > > > > > > > > > fc20-fc3f (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fc20-fc3f > > > > > > > > > > fc40-fc5f (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fc40-fc5f > > > > > > > > > > fc60-fc7f (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fc60-fc7f > > > > > > > > > > fc80-fc9f (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fc80-fc9f > > > > > <- correct Adress Spce > > > > > > > > > > fca0-fcbf (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fca0-fcbf > > > > > > > > > > fcc0-fcdf (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fcc0-fcdf > > > > > > > > > > fce0-fcff (prio 1, RW): alias > > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > > fce0-fcff > > > > > > > > > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > > > > > fda0-fdbf (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fda0-fdbf > > > > > > > > > > fdc0-fddf (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fdc0-fddf > > > > > > > > > > fde0-fdff (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fde0-fdff > > > > > > > > > > fe00-fe1f (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fe00-fe1f > > > > > > > > > > fe20-fe3f (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fe20-fe3f > > > > > > > > > > fe40-fe5f (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fe40-fe5f > > > > > > > > > > fe60-fe7f (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fe60-fe7f > > > > > > > > > > fe80-fe9f (prio 1, RW): alias > > > > > pci_bridge_mem @pci_bridge_pci fe80-fe9f > > > > > > > > > > fc80-fc80 (prio 1, RW): alias > > pci_bridge_pref_mem > > > > > @pci_bridge_pci fc80-fc80 <- Exceptional > > > > > Adress > > > > Space > > > > > > > > This one is empty though right? > > > > > > > > > > > > > > > > > > > We have figured out why this address becomes this value, > > > > > according to pci spec, pci driver can get BAR address size by > > > > > writing 0x to > > > > > > > > > > the pci register firstly, and then read back the value from this > > > > > register. > > > > > > > > > > > > OK however as you show below the BAR being sized is the BAR if a > > > > bridge. Are you then adding a
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > > Hi all, > > > > > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and a > > > > virtio-net nic been attached with bus 4, > > > > > > > > After VM is startup, We ping this nic from host to judge if it is > > > > working normally. Then, we hot add pci devices to this VM with bus 0. > > > > > > > > We found the virtio-net NIC in bus 4 is not working (can not > > > > connect) occasionally, as it kick virtio backend failure with error > > > > below: > > > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > > > - (prio 0, RW): pci_bridge_pci > > > > > > > > fc80-fc803fff (prio 1, RW): virtio-pci > > > > > > > > fc80-fc800fff (prio 0, RW): > > > > virtio-pci-common > > > > > > > > fc801000-fc801fff (prio 0, RW): > > > > virtio-pci-isr > > > > > > > > fc802000-fc802fff (prio 0, RW): > > > > virtio-pci-device > > > > > > > > fc803000-fc803fff (prio 0, RW): > > > > virtio-pci-notify <- io mem unassigned > > > > > > > > … > > > > > > > > > > > > > > > > We caught an exceptional address changing while this problem > > > > happened, show as > > > > follow: > > > > > > > > Before pci_bridge_update_mappings： > > > > > > > > fc00-fc1f (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fc00-fc1f > > > > > > > > fc20-fc3f (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fc20-fc3f > > > > > > > > fc40-fc5f (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fc40-fc5f > > > > > > > > fc60-fc7f (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fc60-fc7f > > > > > > > > fc80-fc9f (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fc80-fc9f > > > > <- correct Adress Spce > > > > > > > > fca0-fcbf (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fca0-fcbf > > > > > > > > fcc0-fcdf (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fcc0-fcdf > > > > > > > > fce0-fcff (prio 1, RW): alias > > > > pci_bridge_pref_mem @pci_bridge_pci > > > > fce0-fcff > > > > > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > > > fda0-fdbf (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fda0-fdbf > > > > > > > > fdc0-fddf (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fdc0-fddf > > > > > > > > fde0-fdff (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fde0-fdff > > > > > > > > fe00-fe1f (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fe00-fe1f > > > > > > > > fe20-fe3f (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fe20-fe3f > > > > > > > > fe40-fe5f (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fe40-fe5f > > > > > > > > fe60-fe7f (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fe60-fe7f > > > > > > > > fe80-fe9f (prio 1, RW): alias > > > > pci_bridge_mem @pci_bridge_pci fe80-fe9f > > > > > > > > fc80-fc80 (prio 1, RW): alias > pci_bridge_pref_mem > > > > @pci_bridge_pci fc80-fc80 <- Exceptional > > > > Adress > > > Space > > > > > > This one is empty though right? > > > > > > > > > > > > > > > We have figured out why this address becomes this value, > > > > according to pci spec, pci driver can get BAR address size by > > > > writing 0x to > > > > > > > > the pci register firstly, and then read back the value from this > > > > register. > > > > > > > > > OK however as you show below the BAR being sized is the BAR if a > > > bridge. Are you then adding a bridge device by hotplug? > > > > No, I just simply hot plugged a VFIO device to Bus 0, another > > interesting phenomenon is If I hot plug the device to other bus, this > > doesn't > happened. > > > > > > > > > > > > We didn't handle this value specially while process pci write in > > > > qemu, the function
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Mon, Dec 10, 2018 at 03:12:53AM +, xuyandong wrote: > On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > > Hi all, > > > > > > > > > > > > In our test, we configured VM with several pci-bridges and a > > > virtio-net nic been attached with bus 4, > > > > > > After VM is startup, We ping this nic from host to judge if it is > > > working normally. Then, we hot add pci devices to this VM with bus 0. > > > > > > We found the virtio-net NIC in bus 4 is not working (can not connect) > > > occasionally, as it kick virtio backend failure with error below: > > > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > > > > > memory-region: pci_bridge_pci > > > > > > - (prio 0, RW): pci_bridge_pci > > > > > > fc80-fc803fff (prio 1, RW): virtio-pci > > > > > > fc80-fc800fff (prio 0, RW): > > > virtio-pci-common > > > > > > fc801000-fc801fff (prio 0, RW): virtio-pci-isr > > > > > > fc802000-fc802fff (prio 0, RW): > > > virtio-pci-device > > > > > > fc803000-fc803fff (prio 0, RW): > > > virtio-pci-notify <- io mem unassigned > > > > > > … > > > > > > > > > > > > We caught an exceptional address changing while this problem happened, > > > show as > > > follow: > > > > > > Before pci_bridge_update_mappings： > > > > > > fc00-fc1f (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fc00-fc1f > > > > > > fc20-fc3f (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fc20-fc3f > > > > > > fc40-fc5f (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fc40-fc5f > > > > > > fc60-fc7f (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fc60-fc7f > > > > > > fc80-fc9f (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fc80-fc9f > > > <- correct Adress Spce > > > > > > fca0-fcbf (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fca0-fcbf > > > > > > fcc0-fcdf (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fcc0-fcdf > > > > > > fce0-fcff (prio 1, RW): alias > > > pci_bridge_pref_mem @pci_bridge_pci fce0-fcff > > > > > > > > > > > > After pci_bridge_update_mappings： > > > > > > fda0-fdbf (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fda0-fdbf > > > > > > fdc0-fddf (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fdc0-fddf > > > > > > fde0-fdff (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fde0-fdff > > > > > > fe00-fe1f (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fe00-fe1f > > > > > > fe20-fe3f (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fe20-fe3f > > > > > > fe40-fe5f (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fe40-fe5f > > > > > > fe60-fe7f (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fe60-fe7f > > > > > > fe80-fe9f (prio 1, RW): alias > > > pci_bridge_mem @pci_bridge_pci fe80-fe9f > > > > > > fc80-fc80 (prio 1, RW): alias > > > pci_bridge_pref_mem > > > @pci_bridge_pci fc80-fc80 <- Exceptional Adress > > Space > > > > This one is empty though right? > > > > > > > > > > > We have figured out why this address becomes this value, according to > > > pci spec, pci driver can get BAR address size by writing 0x > > > to > > > > > > the pci register firstly, and then read back the value from this register. > > > > > > OK however as you show below the BAR being sized is the BAR if a bridge. Are > > you then adding a bridge device by hotplug? > > No, I just simply hot plugged a VFIO device to Bus 0, another interesting > phenomenon is > If I hot plug the device to other bus, this doesn't happened. > > > > > > > > We didn't handle this value specially while process pci write in > > > qemu, the function call stack is: > > > > > > Pci_bridge_dev_write_config > > > > > > -> pci_bridge_write_config > > > > > > -> pci_default_write_config (we update the config[address] value here > > > -> to > > > fc80, which should be 0xfc80 ) > > > > > > ->
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > Hi all, > > > > > > > > In our test, we configured VM with several pci-bridges and a > > virtio-net nic been attached with bus 4, > > > > After VM is startup, We ping this nic from host to judge if it is > > working normally. Then, we hot add pci devices to this VM with bus 0. > > > > We found the virtio-net NIC in bus 4 is not working (can not connect) > > occasionally, as it kick virtio backend failure with error below: > > > > Unassigned mem write fc803004 = 0x1 > > > > > > > > memory-region: pci_bridge_pci > > > > - (prio 0, RW): pci_bridge_pci > > > > fc80-fc803fff (prio 1, RW): virtio-pci > > > > fc80-fc800fff (prio 0, RW): > > virtio-pci-common > > > > fc801000-fc801fff (prio 0, RW): virtio-pci-isr > > > > fc802000-fc802fff (prio 0, RW): > > virtio-pci-device > > > > fc803000-fc803fff (prio 0, RW): > > virtio-pci-notify <- io mem unassigned > > > > … > > > > > > > > We caught an exceptional address changing while this problem happened, > > show as > > follow: > > > > Before pci_bridge_update_mappings： > > > > fc00-fc1f (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fc00-fc1f > > > > fc20-fc3f (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fc20-fc3f > > > > fc40-fc5f (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fc40-fc5f > > > > fc60-fc7f (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fc60-fc7f > > > > fc80-fc9f (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fc80-fc9f > > <- correct Adress Spce > > > > fca0-fcbf (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fca0-fcbf > > > > fcc0-fcdf (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fcc0-fcdf > > > > fce0-fcff (prio 1, RW): alias > > pci_bridge_pref_mem @pci_bridge_pci fce0-fcff > > > > > > > > After pci_bridge_update_mappings： > > > > fda0-fdbf (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fda0-fdbf > > > > fdc0-fddf (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fdc0-fddf > > > > fde0-fdff (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fde0-fdff > > > > fe00-fe1f (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fe00-fe1f > > > > fe20-fe3f (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fe20-fe3f > > > > fe40-fe5f (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fe40-fe5f > > > > fe60-fe7f (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fe60-fe7f > > > > fe80-fe9f (prio 1, RW): alias > > pci_bridge_mem @pci_bridge_pci fe80-fe9f > > > > fc80-fc80 (prio 1, RW): alias > > pci_bridge_pref_mem > > @pci_bridge_pci fc80-fc80 <- Exceptional Adress > Space > > This one is empty though right? > > > > > > > We have figured out why this address becomes this value, according to > > pci spec, pci driver can get BAR address size by writing 0x > > to > > > > the pci register firstly, and then read back the value from this register. > > > OK however as you show below the BAR being sized is the BAR if a bridge. Are > you then adding a bridge device by hotplug? No, I just simply hot plugged a VFIO device to Bus 0, another interesting phenomenon is If I hot plug the device to other bus, this doesn't happened. > > > > We didn't handle this value specially while process pci write in > > qemu, the function call stack is: > > > > Pci_bridge_dev_write_config > > > > -> pci_bridge_write_config > > > > -> pci_default_write_config (we update the config[address] value here > > -> to > > fc80, which should be 0xfc80 ) > > > > -> pci_bridge_update_mappings > > > > ->pci_bridge_region_del(br, br->windows); > > > > -> pci_bridge_region_init > > > > -> > > pci_bridge_init_alias (here pci_bridge_get_base, we use the wrong > > value > > fc80) > > > >
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > Hi all, > > > > In our test, we configured VM with several pci-bridges and a virtio-net nic > been attached with bus 4, > > After VM is startup, We ping this nic from host to judge if it is working > normally. Then, we hot add pci devices to this VM with bus 0. > > We found the virtio-net NIC in bus 4 is not working (can not connect) > occasionally, as it kick virtio backend failure with error below: > > Unassigned mem write fc803004 = 0x1 > > > > memory-region: pci_bridge_pci > > - (prio 0, RW): pci_bridge_pci > > fc80-fc803fff (prio 1, RW): virtio-pci > > fc80-fc800fff (prio 0, RW): virtio-pci-common > > fc801000-fc801fff (prio 0, RW): virtio-pci-isr > > fc802000-fc802fff (prio 0, RW): virtio-pci-device > > fc803000-fc803fff (prio 0, RW): virtio-pci-notify <- io > mem unassigned > > … > > > > We caught an exceptional address changing while this problem happened, show as > follow: > > Before pci_bridge_update_mappings： > > fc00-fc1f (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fc00-fc1f > > fc20-fc3f (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fc20-fc3f > > fc40-fc5f (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fc40-fc5f > > fc60-fc7f (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fc60-fc7f > > fc80-fc9f (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fc80-fc9f <- correct Adress Spce > > fca0-fcbf (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fca0-fcbf > > fcc0-fcdf (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fcc0-fcdf > > fce0-fcff (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fce0-fcff > > > > After pci_bridge_update_mappings： > > fda0-fdbf (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fda0-fdbf > > fdc0-fddf (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fdc0-fddf > > fde0-fdff (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fde0-fdff > > fe00-fe1f (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fe00-fe1f > > fe20-fe3f (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fe20-fe3f > > fe40-fe5f (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fe40-fe5f > > fe60-fe7f (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fe60-fe7f > > fe80-fe9f (prio 1, RW): alias pci_bridge_mem > @pci_bridge_pci fe80-fe9f > > fc80-fc80 (prio 1, RW): alias > pci_bridge_pref_mem > @pci_bridge_pci fc80-fc80 <- Exceptional Adress > Space This one is empty though right? > > > We have figured out why this address becomes this value, according to pci > spec, pci driver can get BAR address size by writing 0x to > > the pci register firstly, and then read back the value from this register. OK however as you show below the BAR being sized is the BAR if a bridge. Are you then adding a bridge device by hotplug? > We didn't handle this value specially while process pci write in qemu, the > function call stack is: > > Pci_bridge_dev_write_config > > -> pci_bridge_write_config > > -> pci_default_write_config (we update the config[address] value here to > fc80, which should be 0xfc80 ) > > -> pci_bridge_update_mappings > > ->pci_bridge_region_del(br, br->windows); > > -> pci_bridge_region_init > > -> > pci_bridge_init_alias (here pci_bridge_get_base, we use the wrong value > fc80) > > -> > memory_region_transaction_commit > > > > So, as we can see, we use the wrong base address in qemu to update the memory > regions, though, we update the base address to > > The correct value after pci driver in VM write the original value back, the > virtio NIC in bus 4 may still sends net packets concurrently with > > The wrong memory region
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
n Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > > Hi all, > > > > > > > > In our test, we configured VM with several pci-bridges and a > > virtio-net nic been attached with bus 4, > > > > After VM is startup, We ping this nic from host to judge if it is > > working normally. Then, we hot add pci devices to this VM with bus 0. > > > > We found the virtio-net NIC in bus 4 is not working (can not connect) > > occasionally, as it kick virtio backend failure with error below: > > > > Unassigned mem write fc803004 = 0x1 > > Thanks for the report. Which guest was used to produce this problem? > > -- > MST I was seeing this problem when I hotplug a VFIO device to guest CentOS 7.4, after that I compiled the latest Linux kernel and it also contains this problem. Thinks, Xu
Re: [Qemu-devel] [BUG]Unassigned mem write during pci device hot-plug
On Sat, Dec 08, 2018 at 11:58:59AM +, xuyandong wrote: > Hi all, > > > > In our test, we configured VM with several pci-bridges and a virtio-net nic > been attached with bus 4, > > After VM is startup, We ping this nic from host to judge if it is working > normally. Then, we hot add pci devices to this VM with bus 0. > > We found the virtio-net NIC in bus 4 is not working (can not connect) > occasionally, as it kick virtio backend failure with error below: > > Unassigned mem write fc803004 = 0x1 Thanks for the report. Which guest was used to produce this problem? -- MST
