On Mon, 2016-09-05 at 12:58 +1000, David Gibson wrote:
>
> With the new chip class per cpu class, does this chip_type field
> serve
> any purpose any more?
>
> > + k->chip_f000f = 0x120d30498000ull;
>
> A comment somewhere explaining what this cryptic value is would be
> nice.
It's snaps
On Mon, 2016-09-05 at 13:39 +1000, David Gibson wrote:
> > +static XScomDevice *xscom_find_target(XScomState *s, uint32_t
> pcb_addr,
> > + uint32_t *range)
> > +{
> > + BusChild *bc;
> > +
> > + QTAILQ_FOREACH(bc, &s->bus->bus.children, sibling) {
> > +
When there are active IOMMU notify registers, the iommu_notify_flag will
cache existing notify flag. When notifiers are triggered, flag will be
checked against the cached result.
Signed-off-by: Peter Xu
---
hw/ppc/spapr_iommu.c | 2 +-
hw/s390x/s390-pci-inst.c | 2 +-
include/exec/memory.h
With the new flag, now we allow to register two kinds of IOMMU
notifiers:
- IOMMU_RW: All DMA mapping changes will be notified.
- IOMMU_NONE: will only be notified when there are cache invalidations.
Here IOMMU_RW is the original scemantics for existing IOMMU notifiers.
VFIO is the only registe
In the thread:
https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg00254.html
Alex proposed a way for vhost DMAR to be enabled without breaking
existing protections on vIOMMU and device assignments. This series
tried to implement the idea, by introducing a IOMMU notifier type for
each IOMM
Intel vIOMMU is still lacking of a complete IOMMU notifier mechanism.
Before that is achieved, let's open a door for vhost DMAR support, which
only requires device-IOTLB based cache invalidations (IOMMU_NONE typed
notifies).
Signed-off-by: Peter Xu
---
hw/i386/intel_iommu.c | 10 ++
1 fi
> Here are the s390x patches I have queued for 2.8 on s390-next.
>
> The biggest chunk are the cpumodel patches. Other than that, the
> introduction of the 2.8 machine and various fixes and enhancements.
>
> I plan to send a pull request once 2.7 has been released.
Hi Conny,
as discussed offlin
On 09/03/2016 05:18 AM, Gonglei (Arei) wrote:
Hi,
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, September 02, 2016 10:05 PM
Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
specification
On 02.09.16 14:16, Ola Liljedahl wrote:
On 0
On 09/04/2016 05:47 PM, Ola Liljedahl wrote:
>
> On 02/09/2016, 16:05, "Alexander Graf" wrote:
>
There is a big problem that the control handle logic is synchronization,
but the data queue
handling logic is asynchronization. We can't combine them into one
queue.
It will de
On 09/05/2016 08:59 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2016-09-05 at 12:58 +1000, David Gibson wrote:
>>
>> With the new chip class per cpu class, does this chip_type field
>> serve
>> any purpose any more?
>>
>>> +k->chip_f000f = 0x120d30498000ull;
>>
>> A comment somewhere explai
Signed-off-by: Longpeng(Mike)
---
hw/i386/pc_piix.c| 17 ++---
hw/i386/pc_q35.c | 16 +---
include/hw/compat.h | 2 ++
include/hw/i386/pc.h | 3 +++
4 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index a07dc
Some software algorithms are based on the hardware's cache info, for example,
for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
a resched IPI and told cpu2 to do the wakeup if they don't share low level
cache. Oppositely, cpu1 will access cpu2's runqueue directly if t
Include migrate_set_speed and migrate_set_downtime inside
migrate_set_parameters respectively for setting maximum migration speed and
expected downtime parameters. Also add the query part for both in qmp and hmp
qemu control interfaces.
Signed-off-by: Ashijeet Acharya
---
hmp-commands.hx
This patchset add virtual L3 cache support.
For KVM's linux guest, this will reduces amouts of IPIs under some workloads.
In our experiments(vm:1*socket,8*cores,2threads workload:SAP-HANA-PB-testsuite),
this reduces 85% guest's resched-IPIs, and the performance improves 7.2%~33.1%.
---
Changes s
On 03/09/2016 01:57, Laine Stump wrote:
>>
>> mdevs do not exist on the host (they do not have a driver on the host
>> because they are not PCI devices) so they do need any management. At
>> least I hope that's good news. :)
>
> What's your definition of "management"? They don't need the same t
Hi Wei,
On 02/09/2016 23:46, Wei Huang wrote:
> Current QEMU will stall guest VM booting under ACPI mode when vcpu count
> is >= 12. Analyzing the booting log, it turns out that DSDT table can't
> be loaded correctly due to "Invalid character(s) in name (0x62303043),
> repaired: [C00*]". This is b
Signed-off-by: Longpeng(Mike)
---
hw/i386/pc_piix.c| 16 +---
hw/i386/pc_q35.c | 13 +++--
include/hw/compat.h | 2 ++
include/hw/i386/pc.h | 3 +++
4 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index a07dc81..
Some software algorithms are based on the hardware's cache info, for example,
for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
a resched IPI and told cpu2 to do the wakeup if they don't share low level
cache. Oppositely, cpu1 will access cpu2's runqueue directly if t
On 09/05/2016 04:58 AM, David Gibson wrote:
> On Wed, Aug 31, 2016 at 06:34:10PM +0200, Cédric Le Goater wrote:
>> This is is an abstraction of a POWER8 chip which is a set of cores
>> plus other 'units', like the pervasive unit, the interrupt controller,
>> the memory controller, the on-chip micro
On 03/09/2016 13:57, John Ferlan wrote:
After creating the vGPU, if required by the host driver, all the other
type ids would disappear from "virsh nodedev-dumpxml pci__86_00_0" too.
>>>
>>> Not wanting to make assumptions, but this reads as if I create one type
>>> 11 vGPU, then I
On 05/09/2016 09:45, Ashijeet Acharya wrote:
> Include migrate_set_speed and migrate_set_downtime inside
> migrate_set_parameters respectively for setting maximum migration
> speed and expected downtime parameters. Also add the query part for
> both in qmp and hmp qemu control interfaces.
>
> Si
This patchset add virtual L3 cache support.
For KVM's linux guest, this will reduces amouts of IPIs under some workloads.
In our experiments(vm:1*socket,8*cores,2threads workload:SAP-HANA-PB-testsuite),
this reduces 85% guest's resched-IPIs, and the performance improves 7.2%~33.1%.
---
Changes si
On Sat, Sep 03, 2016 at 01:53:53AM +0300, Michael S. Tsirkin wrote:
> On Fri, Sep 02, 2016 at 10:21:58AM +0300, Roman Kagan wrote:
> > On Thu, Sep 01, 2016 at 10:26:54PM +0300, Michael S. Tsirkin wrote:
> > > I'm sorry - I don't like this patch. This means that
> > > virtio_balloon_receive_stats wi
On 05/09/2016 09:21, Peter Xu wrote:
> void memory_region_notify_iommu(MemoryRegion *mr,
> -IOMMUTLBEntry entry)
> +IOMMUTLBEntry entry, IOMMUAccessFlags flag)
> {
> assert(memory_region_is_iommu(mr));
> +assert(flag == mr
On Mon, Sep 5, 2016 at 1:31 PM, Paolo Bonzini wrote:
>
>
> On 05/09/2016 09:45, Ashijeet Acharya wrote:
>> Include migrate_set_speed and migrate_set_downtime inside
>> migrate_set_parameters respectively for setting maximum migration
>> speed and expected downtime parameters. Also add the query pa
>
>
> On 09/03/2016 05:18 AM, Gonglei (Arei) wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Friday, September 02, 2016 10:05 PM
> >> Subject: Re: [PATCH v8 1/2] virtio-crypto: Add virtio crypto device
> specification
> >>
> >>
> >>
>
On 05/09/2016 10:11, Ashijeet Acharya wrote:
> > > Include migrate_set_speed and migrate_set_downtime inside
> > > migrate_set_parameters respectively for setting maximum migration
> > > speed and expected downtime parameters. Also add the query part for
> > > both in qmp and hmp qemu control int
Thomas Huth writes:
> The folder does not exist anymore, thus should be removed from the
> MAINTAINERS file, too.
>
> Signed-off-by: Thomas Huth
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b6fb84e..ff45f8c 100644
> --- a/MAINTAIN
On Mon, Sep 5, 2016 at 1:46 PM, Paolo Bonzini wrote:
>
>
> On 05/09/2016 10:11, Ashijeet Acharya wrote:
>> > > Include migrate_set_speed and migrate_set_downtime inside
>> > > migrate_set_parameters respectively for setting maximum migration
>> > > speed and expected downtime parameters. Also add
On Mon, 2016-09-05 at 09:41 +0200, Cédric Le Goater wrote:
> yeah. I have not found a clear definition of all the bits.
>
> I will try to make a macro with what I can collect from the
> specs and the code.
It's the CFAM stuff, there's some doco internally but nothing
releasable publicly...
Chee
Hi,
Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Subject: [Qemu-devel] [PATCH v4 0/2] targte-i386: Add virtual L3 cache support
Type: series
Message-id: 1473061557-41096-1-git
On Fri, Sep 02, 2016 at 05:13:40PM +0200, Pradeep Kiruvale wrote:
> I am planning to implement throttling functionality for virtio-net
> driver using the throttling APIs that exist inside qemu.
Hi Pradeep,
the problem with implementing throttling for the network is that
it's useless if you use t
On 05.09.2016 10:22, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> The folder does not exist anymore, thus should be removed from the
>> MAINTAINERS file, too.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> MAINTAINERS | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/M
On Mon, Sep 05, 2016 at 10:04:42AM +0200, Paolo Bonzini wrote:
>
>
> On 05/09/2016 09:21, Peter Xu wrote:
> > void memory_region_notify_iommu(MemoryRegion *mr,
> > -IOMMUTLBEntry entry)
> > +IOMMUTLBEntry entry, IOMMUAccessFlags fla
Hi Alberto,
Thanks for your reply.
>
> > I am planning to implement throttling functionality for virtio-net
> > driver using the throttling APIs that exist inside qemu.
>
> Hi Pradeep,
>
> the problem with implementing throttling for the network is that
> it's useless if you use the vhost_net ker
Let's implement our two hooks so we can support CPU models.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_models.c | 75 +++-
target-s390x/cpu_models.h | 50
target-s390x/kvm.c| 295 ++
3 file
Update against 29b4817d4018 ("Linux 4.8-rc1")
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
include/standard-headers/linux/input-event-codes.h | 32 +
include/standard-headers/linux/input.h | 1 +
include/standard-headers/linux/virtio_config.h | 1
Let's use the generated groups to create feature group representations for
the user. These groups can later be used to enable/disable multiple
features in one shot and will be used to reduce the amount of reported
features to the user if all subfeatures are in place.
We want to work on features us
From: Michael Mueller
This patch introduces the helper "gen-features" which allows to generate
feature list definitions at compile time. Its flexibility is better and the
error-proneness is lower when compared to static programming time added
statements.
The helper includes "target-s390x/cpu_fea
Let's factor out the common code of "read cpu info" and "read scp
info". This will make the introduction of new cpu entry fields easier.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
d
It might be of interest for tooling whether a CPU definition can be safely
used when migrating, or if e.g. CPU features might get lost during
migration when migrationg from/to a different QEMU version or host, even if
the same compatibility machine is used.
Also, we want to know if a CPU definitio
If we have a lowest ibc, we can indicate the ibc to the guest.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 2 ++
include/hw/s390x/sclp.h | 3 ++-
target-s390x/cpu_models.c | 21 +
target-s390x/cpu_models.h | 12
4
In order to expand CPU models, we create temporary cpus that handle the
feature/group parsing. Only CPU feature properties are expanded.
When converting the data structure back, we always fall back to the
static base CPU model, which is by definition migration-safe.
Acked-by: Cornelia Huck
Signe
The sclp "read cpu info" and "read scp info" commands can include
features for the cpu info and configuration characteristics (extended),
decribing some advanced features available in the configuration.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
include/hw/s390x/sclp.h | 12 ++
Feature groups will be very helpful to reduce the amount of features
typically available in sane configurations. E.g. the MSA facilities
introduced loads of subfunctions, which could - in theory - go away
in the future, but we want to avoid reporting hundrets of features to
the user if usually all
A CPU model consists of a CPU definition, to which delta changes are
applied - features added or removed (e.g. z13-base,vx=on). In addition,
certain properties (e.g. cpu id) can later on change during migration
but belong into the CPU model. This data will later be filled from the
host model in the
Let's implement that interface by reusing our convertion code implemented
for expansion.
We use CPU generations and CPU features to calculate the result. This
means, that a zEC12 cannot simply be converted into a z13 by stripping
of features. This is required, as other magic values (e.g. maximum
a
From: Michael Mueller
The patch introduces s390x CPU features (most of them refered to as
facilities) along with their discription and some functions that will be
helpful when working with the features later on.
Please note that we don't introduce all known CPU features, only the
ones currently
Let's expose the description and migration safety and whether a definition
is static, as class properties, this can be helpful in the future.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu.c| 1 +
target-s390x/cpu.h| 1 +
target-s390x/cpu_models.
To be able to query the correct host model for the "none" machine,
let's allow runtime-instrumentation for that machine.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-virtio-ccw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/s390x/s390-virtio-ccw.c b/
We have to test if a configured CPU model is runnable in the current
configuration, and if not report why that is the case. This is done by
comparing it to the maximum supported model (host for KVM or z900 for TCG).
Also, we want to do some base sanity checking for a configured CPU model.
We'll ca
Hi,
no logical changes this time.
In this version, cross-compilation and compilation with mingw32 are fixed.
Our feature generation script gen-features has to be compiled for the
host architecture, where we do the compilation and bitmaps cannot be
directly initialized from the generated data, bec
We have three different blocks in the SCLP read-SCP information response
that indicate sclp features. Let's prepare propagation.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 9 +
target-s390x/cpu_models.c | 14 ++
target-s390x/cpu
On Mon, 5 Sep 2016 10:52:14 +0200
David Hildenbrand wrote:
> Hi,
>
> no logical changes this time.
>
> In this version, cross-compilation and compilation with mingw32 are fixed.
> Our feature generation script gen-features has to be compiled for the
> host architecture, where we do the compila
This patch introduces two CPU models, "host" and "qemu".
"qemu" is used as default when running under TCG. "host" is used
as default when running under KVM. "host" cannot be used without KVM.
"host" is not migration-safe. They both inherit from the base s390x CPU,
which is turned into an abstract c
Let's provide a standardized interface to baseline two CPU models, to
create a third, compatible one. This is especially helpful when two
CPU models are not identical, but a CPU model is required that is
guaranteed to run under both configurations, where the original models run.
"query-cpu-model-b
The mha is provided in the CPU model, so get any CPU and extract the value.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 1 +
include/hw/s390x/sclp.h | 3 ++-
target-s390x/cpu_models.c | 14 ++
target-s390x/cpu_models.h | 1 +
4 files
Let's provide a standardized interface to expand CPU models. This interface
can be used by tooling to get details about a specific CPU model in a
certain configuration, e.g. about the "host" model.
To take care of all architectures, two detail levels for an expansion
are introduced. Certain archit
Let's add all features and feature groups as properties to all CPU models.
If the "host" CPU model is unknown, we can neither query nor change
features. KVM will just continue to work like it did until now.
We will not allow to enable features that were not part of the original
CPU model, because
This patch adds the CPU model definitions that are known on s390x -
like z900, zBC12 or z13. For each definition, introduce two CPU models:
1. Base model (e.g. z13-base): Minimum feature set we expect to be around
on all z13 systems. These models are migration-safe and will never
change.
2.
If we have certain features enabled, we have to migrate additional state
(e.g. vector registers or runtime-instrumentation registers). Let the
CPU model control that unless we have no "host" CPU model in the KVM
case. This will later on be the case for compatibility machines, so
migration from QEMU
Compatibility machines that touch runtime-instrumentation should not
be used with the CPU model. Otherwise the host model will look different,
depending on the QEMU machine QEMU has been started with.
So let's simply disable the host model for existing compatibility machines
that all disable ri. T
Let's implement that interface by reusing our conversion code and
lookup code for CPU definitions.
In order to find a compatible CPU model, we first detect the maximum
possible CPU generation and then try to find a maximum model, satisfying
all base features (not exceeding the maximum generation).
Let's provide a standardized interface to compare two CPU models.
"query-cpu-model-compare" takes two models and returns how they compare
in a specific configuration.
The result will give guarantees about runnability. E.g. if a CPU model A
is a subset of CPU model B, model A is guaranteed to run
hmfai is provided on CPU models >= z196. Let's propagate it properly.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 1 +
include/hw/s390x/sclp.h | 3 ++-
target-s390x/cpu_models.c | 14 ++
target-s390x/cpu_models.h | 1 +
4 files chang
Starting with recent kernels, if the cmma attributes are available, we
actually have hardware support. Enabling CMMA then means providing the
guest VCPU with CMM, therefore enabling its CMM facility.
Let's not blindly enable CMM anymore but let's control it using CPU models.
For disabled CPU model
Hi all, sorry for the repeat emails...I sent in a question during the days
running up to the 2.7 release and I understand you were all busy working to
get that complete.
My question is about whether my expectations are correct or not with TPM
passthrough. I have a known good device but when passe
Hi
On Sat, Sep 3, 2016 at 5:36 PM Wang, Wei W wrote:
> Marc-André and I just got different thoughts about a design direction. I
> prefer to have all the frontend virtio devices (net, scsi, console etc.)
> from the same VM to be supported by one backend vhost-pci device (N-1),
> while Marc-André
On Mon, Sep 05, 2016 at 04:59:23PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2016-09-05 at 12:58 +1000, David Gibson wrote:
> >
> > With the new chip class per cpu class, does this chip_type field
> > serve
> > any purpose any more?
> >
> > > + k->chip_f000f = 0x120d30498000ull;
> >
As the CPU model now controls msa3, trying to set wrapping keys without
msa3 being around/enable in the kernel will produce misleading errors.
So let's simply not configure key wrapping if msa3 is not enabled and
make compat machines with disabled CPU model work correctly.
Signed-off-by: David Hi
The net/colo.c is used by colo-compare and filter-rewriter.
this can share common data structure like net packet,
and other functions.
Signed-off-by: Zhang Chen
Signed-off-by: Li Zhijian
Signed-off-by: Wen Congyang
---
net/Makefile.objs | 1 +
net/colo-compare.c | 113 ++
On 03/09/2016 08:33, P J P wrote:
> From: Prasad J Pandit
>
> In PVSCSI paravirtual SCSI bus, the request descriptor data
> length is defined to be 64 bit. While building SG list from
> a request descriptor, it gets truncated to 32bit in routine
> 'pvscsi_convert_sglist'. This could lead to an
On 05/09/2016, 09:40, "Alexander Graf" wrote:
>On 09/04/2016 05:47 PM, Ola Liljedahl wrote:
>>
>> On 02/09/2016, 16:05, "Alexander Graf" wrote:
>>
> There is a big problem that the control handle logic is
>synchronization,
> but the data queue
> handling logic is asynchronizati
Adding Paolo.
Michal Privoznik writes:
> On 02.09.2016 01:11, Alex Williamson wrote:
>> Hey,
>>
>> I'm out of my QOM depth, so I'll just beg for help in advance. I
>> noticed in testing vfio-pci hotunplug that the host seems to be trying
>> to reclaim the device before QEMU is actually done wi
Hi,
> It appears that "eject" the stick in the guest may also actually eject it on
> the host,
Yes, that is the case.
> which however, is not rational.
Why? I see the same behavior on physical machines. If I want to use a
usb stick after ejecting it I have to unplug and re-plug it.
> Could
Upon hmp_host_net_remove(), the appropriate -net client is deleted
(according to the given vlan_id and device id), as well as the
corresponsing hub port.
However, the relevant '-net' option that was added by former
hmp_host_net_add() call is still present in "net" options group.
This makes the fo
John Snow writes:
> On 09/02/2016 01:44 AM, Markus Armbruster wrote:
>> John Snow writes:
>>
>>> If a device still has an attached BDS because the medium has not yet
>>> been removed, we will be unable to migrate to a new host because
>>> blk_flush will return an error for that backend.
>>>
>>>
Eduardo Habkost writes:
> While trying to fix the original bug in v1, another bug was fixed
> by accident: TCG initialization of dirty_log_mask was broken when
> using memory backends.
>
> The fix, on the other hand, broke vhost-user-test because it
> relied on TCG, even though TCG is incompatibl
On 05/09/2016 11:23, Markus Armbruster wrote:
>> >
>> > On the other hand, it is clearly documented that the DEVICE_DELETED
>> > event is sent as soon as guest acknowledges completion of device
>> > removal. So libvirt's buggy if we'd follow documentation strictly. But
>> > then again, I don't se
On 09/05/2016 09:41 AM, David Gibson wrote:
> On Mon, Sep 05, 2016 at 04:59:23PM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2016-09-05 at 12:58 +1000, David Gibson wrote:
>>>
>>> With the new chip class per cpu class, does this chip_type field
>>> serve
>>> any purpose any more?
>>>
+
COLO-proxy is a part of COLO project. COLO project is
composed of COLO-frame, COLO-proxy and block-replication.
It is used to compare the network package to help COLO
decide whether to do checkpoint. With COLO-proxy's help,
COLO greatly improves the performance.
The filter-redirector, filter-mirro
Filter-rewriter is a part of COLO project.
It will rewrite some of secondary packet to make
secondary guest's tcp connection established successfully.
In this module we will rewrite tcp packet's ack to the secondary
from primary,and rewrite tcp packet's seq to the primary from
secondary.
usage:
c
We add TCP,UDP,ICMP packet comparison to replace
IP packet comparison. This can increase the
accuracy of the package comparison.
Less checkpoint more efficiency.
Signed-off-by: Zhang Chen
Signed-off-by: Li Zhijian
Signed-off-by: Wen Congyang
---
net/colo-compare.c | 145 +++
Am 01.09.2016 um 22:21 hat Holger Schranz geschrieben:
> Hello,
>
> we need help for an issue we have sice QEMU 2.7.
> May be we use the wrong mailing list. If so please let me know which
> mail list we have to use to report problems in QEMU.
>
> Best regards
>
> Holger
Eric, a quick look sugge
Introduce the design of COLO-proxy, and how to use it.
Signed-off-by: Zhang Chen
---
docs/colo-proxy.txt | 188
1 file changed, 188 insertions(+)
create mode 100644 docs/colo-proxy.txt
diff --git a/docs/colo-proxy.txt b/docs/colo-proxy.txt
n
On 05/09/2016 10:38, Peter Xu wrote:
> However in this patch I was not meant to do that. I made it an
> exclusive flag to identify two different use cases. I don't know
> whether this is good, but at least for Intel IOMMU's current use case,
> these two types should be totally isolated from each
We will rewrite tcp packet secondary received and sent.
When colo guest is a tcp server.
Firstly, client start a tcp handshake. the packet's seq=client_seq,
ack=0,flag=SYN. COLO primary guest get this pkt and mirror(filter-mirror)
to secondary guest, secondary get it use filter-redirector.
Then,pr
Jhash will be used by colo-compare and filter-rewriter
to save and lookup net connection info
Signed-off-by: Zhang Chen
Signed-off-by: Li Zhijian
Signed-off-by: Wen Congyang
---
include/qemu/jhash.h | 59
net/colo.h | 1 +
2 files
This a COLO net ascii figure:
Primary qemu
Secondary qemu
+--+
++
| +--
On 05/09/2016 11:50, P J P wrote:
> Hello Paolo, all
>
> +-- On Mon, 5 Sep 2016, Paolo Bonzini wrote --+
> | > -uint64_t data_length = r->req.dataLen;
> | > +uint32_t data_length = r->req.dataLen;
> |
> | Why is this needed if you remove the cast in MIN, below?
>
> The outer while lo
Am 01.09.2016 um 16:08 hat Stefan Hajnoczi geschrieben:
> On Thu, Sep 01, 2016 at 12:18:10PM +0100, Peter Maydell wrote:
> > I know 2.7 isn't quite out the door yet, but I figured we should
> > kick off the discussion of 2.8's schedule. At the QEMU Summit there
> > was some discussion on how we're
If primary packet is same with secondary packet,
we will send primary packet and drop secondary
packet, otherwise notify COLO frame to do checkpoint.
If primary packet comes but secondary packet does not,
after REGULAR_PACKET_CHECK_MS milliseconds we set
the primary packet as old_packet,then do a c
Paolo Bonzini writes:
> Add a mutex for the CPU list to system emulation, as it will be used to
> manage safe work. Abstract manipulation of the CPU list in new functions
> cpu_list_add and cpu_list_remove.
>
> Signed-off-by: Paolo Bonzini
> index a440bcb..73d0c2f 100644
What tree are you ba
Hello Paolo, all
+-- On Mon, 5 Sep 2016, Paolo Bonzini wrote --+
| > -uint64_t data_length = r->req.dataLen;
| > +uint32_t data_length = r->req.dataLen;
|
| Why is this needed if you remove the cast in MIN, below?
The outer while loop below is controlled by 'data_length'. The cast in M
We use net/colo.h to track connection and parse packet
Signed-off-by: Zhang Chen
Signed-off-by: Li Zhijian
Signed-off-by: Wen Congyang
---
net/colo.c| 14 ++
net/colo.h| 1 +
net/filter-rewriter.c | 50 ++
3 f
Add qemu_chr_add_handlers_full() API, we can use
this API pass in a GMainContext,make handler run
in the context rather than main_loop.
This comments from Daniel P . Berrange.
Signed-off-by: Zhang Chen
Signed-off-by: Li Zhijian
Signed-off-by: Wen Congyang
Reviewed-by: Daniel P. Berrange
---
i
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [Patch v4 00/30] s390x CPU models: exposing features
Type: series
Message-id: 20160905085244.99980-1-d...@linux.vnet.ibm.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
add Zhang Chen and Li zhijian as co-maintainers of COLO-proxy.
Signed-off-by: Zhang Chen
Signed-off-by: Li Zhijian
Signed-off-by: Wen Congyang
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b6fb84e..4781f9f 100644
--- a/MAINTAINERS
In this patch we use kernel jhash table to track
connection, and then enqueue net packet like this:
+ CompareState ++
| |
+---+ +---+ +---+
|conn list +--->conn +->conn |
+---+ +-
Hi Gerd,
Thank you very much for your reply, it's very useful!
Regards,
-Gonglei
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Monday, September 05, 2016 4:58 PM
> To: wangxin (U)
> Cc: qemu-devel@nongnu.org; fuweiwei (C); Gonglei (Arei)
> Subject: Re: qu
1 - 100 of 504 matches
Mail list logo
