Ping.
On Wed, Jul 5, 2017 at 10:54 AM, Sameeh Jubran wrote:
> From: Sameeh Jubran
>
> This patch series fixes qemu-ga's main service behaviour on Windows
> by listening to the virtio-serial device's events.
>
> For more info on why this series is needed checkout the commit message
> of the thir
When a guest that has several hotplugged dimms is migrated, on
destination it will fail to resume. Because regions on source
are merged and on destination the order of realizing devices
is different from on source with dimms, so when part of devices
are realizd some region can not be merged.That ma
> On Sat, Jul 22, 2017 at 01:49:20PM +0800, peng.h...@zte.com.cn wrote:
> > some regions can not merge when just part of devices have realized.
> >
> > when all devices are realized on destination, these regions can be merged
> > again
> >
> > and the used slots can satisfy the vhost slot
On Sun, Jul 23, 2017 at 01:11:50AM +0300, Aleksandr Bezzubikov wrote:
> In case of Red Hat PCI bridges reserve additional buses, which number is
> provided
> in a vendor-specific capability.
>
> Signed-off-by: Aleksandr Bezzubikov
> ---
> src/fw/pciinit.c | 14 --
> 1 file changed,
On Sun, Jul 23, 2017 at 01:11:49AM +0300, Aleksandr Bezzubikov wrote:
> On PCI init PCI bridge devices may need some
> extra info about bus number to reserve, IO, memory and
> prefetchable memory limits. QEMU can provide this
> with special vendor-specific PCI capability.
>
> This capability is in
On Sat, Jul 22, 2017 at 09:24:27AM +, Marc-André Lureau wrote:
>
>
> On Sat, Jul 22, 2017 at 2:35 AM Michael S. Tsirkin wrote:
>
> On Fri, Jul 21, 2017 at 11:19:04AM +, Marc-André Lureau wrote:
> > Hi
> >
> > On Fri, Jul 21, 2017 at 7:18 AM w00273186
> wrote:
> >
>
On Sat, Jul 22, 2017 at 01:49:20PM +0800, peng.h...@zte.com.cn wrote:
> some regions can not merge when just part of devices have realized.
>
> when all devices are realized on destination, these regions can be merged
> again
>
> and the used slots can satisfy the vhost slot limit as on sourc
On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote:
> On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote:
> > On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote:
> > > On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:
> > > > So the way I see it, there are several issues:
> > > >
> > > >
To enable hotplugging of a newly created pcie-pci-bridge,
we need to tell firmware (SeaBIOS in this case) to reserve
additional buses for pcie-root-port, that allows us to
hotplug pcie-pci-bridge into this root port.
The number of buses to reserve is provided to the device via a corresponding
prop
Signed-off-by: Aleksandr Bezzubikov
---
hw/pci-bridge/pcie_root_port.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
index b0e49e1..ca92d85 100644
--- a/hw/pci-bridge/pcie_root_port.c
+++ b/hw/pci-bridge/pcie_root_port.c
@
On PCI init PCI bridges may need some
extra info about bus number to reserve, IO, memory and
prefetchable memory limits. QEMU can provide this
with special vendor-specific PCI capability.
Sizes of limits match ones from
PCI Type 1 Configuration Space Header,
number of buses to reserve occupies onl
This series introduces a new device - generic PCI Express to PCI bridge,
and also makes all necessary changes to enable hotplug of the bridge itself
and any device into the bridge.
Obvious reasons to remain RFC:
1. The new PCI capability: layout, creation interface.
2. Windows SHPC issue - devices
Signed-off-by: Aleksandr Bezzubikov
---
hw/pci-bridge/Makefile.objs | 2 +-
hw/pci-bridge/pcie_pci_bridge.c | 151
include/hw/pci/pci.h| 1 +
3 files changed, 153 insertions(+), 1 deletion(-)
create mode 100644 hw/pci-bridge/pcie_pci_b
Unmask previously masked SHPC feature in _OSC method.
Signed-off-by: Aleksandr Bezzubikov
---
hw/i386/acpi-build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 6b7bade..0d99585 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i38
Signed-off-by: Aleksandr Bezzubikov
---
hw/pci-bridge/pcie_pci_bridge.c | 63 -
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
index 0991a7b..38f665f 100644
--- a/hw/pci-bridge
On PCI init PCI bridge devices may need some
extra info about bus number to reserve, IO, memory and
prefetchable memory limits. QEMU can provide this
with special vendor-specific PCI capability.
This capability is intended to be used only
for Red Hat PCI bridges, i.e. QEMU cooperation.
Sizes of l
In case of Red Hat PCI bridges reserve additional buses, which number is
provided
in a vendor-specific capability.
Signed-off-by: Aleksandr Bezzubikov
---
src/fw/pciinit.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
in
Now PCI bridges get a bus range number on a system init,
basing on currently plugged devices. That's why when one wants to hotplug
another bridge,
it needs his child bus, which the parent is unable to provide (speaking about
virtual device).
The suggested workaround is to have vendor-specific cap
Refactor pci_find_capability function to get bdf instead of
a whole pci_device* as the only necessary field for this function
is still bdf.
It greatly helps when we have bdf but not pci_device.
Signed-off-by: Aleksandr Bezzubikov
---
src/fw/pciinit.c| 4 ++--
src/hw/pcidevice.c | 12 +
Signed-off-by: Aleksandr Bezzubikov
---
src/hw/pci_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
index 4ac73b4..db2e694 100644
--- a/src/hw/pci_ids.h
+++ b/src/hw/pci_ids.h
@@ -2263,6 +2263,8 @@
#define PCI_DEVICE_ID_KORENIX_JETCARDF00x16
On Fri, Jul 21, 2017 at 8:58 AM, Stefan Hajnoczi wrote:
> On Fri, Jul 21, 2017 at 09:29:15AM -0400, Pankaj Gupta wrote:
>>
>> > > A] Problems to solve:
>> > > --
>> > >
>> > > 1] We are considering two approaches for 'fake DAX flushing interface'.
>> > >
>> > > 1.1] fake dax with
On 07/21/2017 02:35 PM, Emilio G. Cota wrote:
static void arm_post_translate_insn(CPUARMState *env, DisasContext *dc)
{
+if (dc->condjmp && !dc->base.is_jmp) {
+gen_set_label(dc->condlabel);
+dc->condjmp = 0;
+}
+
Thanks for the catch.
I have merged the !dc->base.is
On 07/21/2017 11:37 AM, Emilio G. Cota wrote:
gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
+dc->is_jmp = DISAS_NORETURN;
gen_exception_internal_insn already sets dc->is_jmp to DISAS_NORETURN,
as per patch 04/34:
@@ -304,7 +304,7 @@ static voi
On 07/21/2017 12:35 PM, Lluís Vilanova wrote:
+#define DISAS_TOO_MANY 5
Why is this one not added as a generic define too (like DISAS_NORETURN in prev
patch)?
Because I use NORETURN in the arm cleanup, prior to conversion to the enum,
whereas I do not use TOO_MANY outside the i386 port. I s
If an offset of ports is specified to the inet_listen_saddr function(),
and two or more processes tries to bind from these ports at the same time,
occasionally more than one process may be able to bind to the same
port. The condition is detected by listen() but too late to avoid a failure.
This fu
On Sat, Jul 22, 2017 at 2:35 AM Michael S. Tsirkin wrote:
> On Fri, Jul 21, 2017 at 11:19:04AM +, Marc-André Lureau wrote:
> > Hi
> >
> > On Fri, Jul 21, 2017 at 7:18 AM w00273186
> wrote:
> >
> > From: Yunjian Wang
> >
> > "nc" is freed after hotplug vhost-user, but the watcher don
Richard Henderson writes:
> We can check for single-step just once.
> Signed-off-by: Richard Henderson
Reviewed-by: Lluís Vilanova
> ---
> target/arm/translate.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
> diff --git a/target/arm/translate.c b/target/arm/translat
On Fri, Jul 21, 2017 at 10:34:16AM +0100, Stefan Hajnoczi wrote:
There is not much getting started documentation for qemu-iotests. This
patch explains how to create a new test and covers the overall testing
approach.
Cc: Ishani Chugh
Signed-off-by: Stefan Hajnoczi
---
tests/qemu-iotests/READM
There's a potential race condition between multiple bind()'s
attempting to bind to the same port, which occasionally
allows more than one bind to succeed against the same port.
When a subsequent listen() call is made with the same socket
only one will succeed.
The current QEMU code does however n
##
If I read this right port is mandatory, correct?
Okay, so it sounds like reusing InetSocket directly may not be possible.
But there's still the interface question of whether we want dual 'ipv4'
and 'ipv6' switches to allow finer-grain control over which (or both)
families to be used.
I
Another refactoring step to prepare for the problem
exposed by the test-listen test.
This time simplify and reorganize the IPv6 specific extra
measures and move it out of the for loop to increase
code readability. No semantic changes.
Signed-off-by: Knut Omang
---
util/qemu-sockets.c | 69 +
First refactoring step to prepare for fixing the problem
exposed with the test-listen test in the previous commit
Signed-off-by: Knut Omang
---
util/qemu-sockets.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/util/qemu-sockets.c b/util/qemu-socket
This series contains:
* a unit test that exposes a race condition which causes QEMU to fail
to find a port even when there is plenty of available ports.
* a refactor of the qemu-sockets inet_listen_saddr() function
to better handle this situation.
Changes from v4:
* Move the complexity of recr
33 matches
Mail list logo
