Adds a new interface type using UDP sockets, this seems only applicable
to QEMU but have edited tree-wide to support the new interface type.
The interface type required the addition of a "destaddr" (destination
address), this then maps into the following xml and qemu call.
>> static virCPUDataPtr
>> ppc64DriverNodeData(virArch arch)
>> {
>> -virCPUDataPtr cpuData;
>> +virCPUDataPtr nodeData;
>> +virCPUppc64Data *data;
>>
>> -if (VIR_ALLOC(cpuData) < 0)
>> -return NULL;
>> +if (VIR_ALLOC(nodeData) < 0)
>> +goto error;
>>
>>
On 08/07/2015 11:39 AM, Andrea Bolognani wrote:
> Use a typedef instead of the plain struct and heap allocation. This
> will make it easier to extend the ppc64 specific CPU data later on.
> ---
> src/cpu/cpu.h| 2 +-
> src/cpu/cpu_ppc64.c | 86
> +++
Commit 1ce7c1d2 changed domainGetInfo to set virDomainInfoPtr->memory
to 0 when domain is inactive, but only did this for the LXC and QEMU
drivers. Make a similar change to the other virt drivers so they all
behave the same.
Signed-off-by: Jim Fehlig
---
FYI, commit 1ce7c1d2 also broke libvirt-t
Commit f86ae403 moved acquiring a job from libxlDomainStart()
to its callers. One spot missed was in libxlDoMigrateReceive().
Acquire a job in libxlDoMigrateReceive() before calling
libxlDomainStart().
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_migration.c | 20 +---
1 file ch
Failure of libxl_domain_suspend() does not leave the domain in
a suspended state, so no need to call libxl_domain_resume(),
which btw will fail with "domain not suspended".
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_migration.c | 14 --
1 file changed, 14 deletions(-)
diff --git
This series fixes a few issues found while testing migration with
latest Xen and libvirt. See the individual patches for details.
V2: rebased to latest git master and address Olaf's comment
from V1.
Jim Fehlig (3):
libxl: fix ref counting of libxlMigrationDstArgs
libxl: don't attempt to
This patch fixes some flawed logic around ref counting the
libxlMigrationDstArgs object.
First, when adding sockets to the event loop with
virNetSocketAddIOCallback(), the generic virObjectFreeCallback()
was registered as a free function, with libxlMigrationDstArgs as
its parameter. A reference wa
On Fri, 2015-08-07 at 10:14 +0200, Jiri Denemark wrote:
>
> According to our discussion sometime last week I think PPC64 driver
> should never create a CPU definition with fallback='allow' since it
> doesn't make any sense for PPC. In other words, this series is
> missing
> one patch that would m
This is yet another variation of POWER8. The PVR information comes
from arch/powerpc/kernel/cputable.c in the Linux kernel tree.
---
src/cpu/cpu_map.xml | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index 0895ada..d2469ee 100644
--- a/src/cpu/cpu_map
The test cases cover the cpuCompare(), cpuBaseline() and
cpuNodeData() implementation.
---
tests/cputest.c | 16
tests/cputestdata/ppc64-baseline-incompatible-models.xml | 14 ++
tests/cputestdata/ppc64-baseline-legacy.xml
Instead of relying on a hard-coded mask value, read it from the CPU
map XML and use it when looking up models by PVR.
---
src/cpu/cpu_map.xml | 14 +++---
src/cpu/cpu_ppc64.c | 24 ++--
src/cpu/cpu_ppc64_data.h | 1 +
3 files changed, 22 insertions(+), 17 del
The upcoming commits will make heavy modifications to the ppc64
driver, split so that it's easier to review the changes.
Instead of updating the test cases so that they pass, possibly
only to update them again with the following commit, disable them
for the time being.
Another commit will update
Now that all the changes have been implemented we can run the
test cases once again, after updating them to reflect the new
behaviour.
---
tests/cputest.c | 16
.../cputestdata/ppc64-baseline-incompatible-vendors.xml | 4 ++--
tests/cpute
Unlike what happens on x86, on ppc64 you can't mix and match CPU
features to obtain the guest CPU you want regardless of the host
CPU, so the concept of model fallback doesn't apply.
Make sure CPU definitions emitted by the driver, eg. as output of
the cpuBaseline() and cpuUpdate() calls, reflect
ppc64Compute(), called by cpuNodeData(), is used not only to retrieve
the driver-specific data associated to a guest CPU definition, but
also to check whether said guest CPU is compatible with the host CPU.
If the user is not interested in the CPU data, it's perfectly fine
to pass a NULL pointer i
All previously recognized CPU models (POWER7_v2.1, POWER7_v2.3,
POWER7+_v2.1 and POWER8_v1.0) are internally converted to the
corrisponding generation name so that existing guests don't stop
working.
---
src/cpu/cpu_ppc64.c | 36 ++--
1 file changed, 34 insertions(+
Use multiple PVRs per CPU model to reduce the number of models we
need to keep track of.
Remove specific CPU models (eg. POWER7+_v2.1): the corresponding
generic CPU model (eg. POWER7) should be used instead to ensure
the guest can be booted on any compatible host.
Get rid of all the entries that
This ensures comparison of two CPU definitions will be consistent
regardless of the fact that it is performed using cpuCompare() or
cpuGuestData(). The x86 driver uses the same exact code.
---
src/cpu/cpu_ppc64.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff -
This will allow us to perform PVR matching more broadly, eg. consider
both POWER8 and POWER8E CPUs to be the same even though they have
different PVR values.
---
src/cpu/cpu_ppc64.c | 72
src/cpu/cpu_ppc64_data.h | 8 +-
2 files changed, 6
Limitations of the POWER architecture mean that you can't run
eg. a POWER7 guest on a POWER8 host when using KVM. This applies
to all guests, not just those using VIR_CPU_MATCH_STRICT in the
CPU definition; in fact, exact and strict CPU matching are
basically the same on ppc64.
This means, of cour
The information is not used anywhere in libvirt.
No functional changes.
---
src/cpu/cpu_map.xml | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index b924bd3..6387ce4 100644
--- a/src/cpu/cpu_map.xml
+++ b/src/cpu/cpu_map.xml
@@ -1385,31 +1385,26
No functional changes.
---
tests/cputestdata/ppc64-baseline-1-result.xml | 3 ---
1 file changed, 3 deletions(-)
delete mode 100644 tests/cputestdata/ppc64-baseline-1-result.xml
diff --git a/tests/cputestdata/ppc64-baseline-1-result.xml
b/tests/cputestdata/ppc64-baseline-1-result.xml
deleted fi
Having the functions grouped together this way will avoid further
shuffling around down the line.
No functional changes.
---
src/cpu/cpu_ppc64.c | 127 +---
1 file changed, 62 insertions(+), 65 deletions(-)
diff --git a/src/cpu/cpu_ppc64.c b/src/cp
---
src/cpu/cpu_ppc64.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/cpu/cpu_ppc64.c b/src/cpu/cpu_ppc64.c
index 05ff8f2..18dbf86 100644
--- a/src/cpu/cpu_ppc64.c
+++ b/src/cpu/cpu_ppc64.c
@@ -163,17 +163,10 @@ ppc64ModelFromCPU(const virCPUDef *cpu,
if
A test is considered successful if the obtained result matches
the expected result: if that's not the case, whether because a
test that was expected to succeed failed or because a test that
was supposed to fail succeeded, then something's not right and
we want the user to know about this.
On the o
Patches 01-07 are cleanups, 08-10 are bug fixes and 11-20
improve the driver.
Changes in v2:
* Implement compatibility with guests defined on older
libvirt versions
* Always use fallback='forbid' when emitting CPU definitions
* Update all tests in one go instead of changing them
s
Use a typedef instead of the plain struct and heap allocation. This
will make it easier to extend the ppc64 specific CPU data later on.
---
src/cpu/cpu.h| 2 +-
src/cpu/cpu_ppc64.c | 86
src/cpu/cpu_ppc64_data.h | 3 +-
3 files ch
Use briefer checks, eg. (!model) instead of (model == NULL), and
avoid initializing to NULL a pointer that would be assigned in
the first line of the function anyway.
Also remove a pointless NULL assignment.
No functional changes.
---
src/cpu/cpu_ppc64.c | 33 -
1
Use the ppc64Driver prefix for all functions that are used to
fill in the cpuDriverPPC64 structure, ie. those that are going
to be called by the generic CPU code.
This makes it clear which functions are exported and which are
implementation details; it also gets rid of the ambiguity that
affected
https://bugzilla.redhat.com/show_bug.cgi?id=1022292
The following XML really does not make any sense:
There can't be a negative packet rate. Well, so far we haven't
assigned any meaning to it. So reject it unless users harm themselves,
because otherwise we turn the negative numbers into really
https://bugzilla.redhat.com/show_bug.cgi?id=1022292
The following XML really does not make any sense:
There can't be a negative packet rate. Well, so far we haven't
assigned any meaning to it. So reject it unless users harm themselves,
because otherwise we turn the negative numbers into really
On Fri, Aug 07, 2015 at 03:27:29PM +0300, Pavel Fedin wrote:
Hello!
The qemuxml2argvtest mocks the capability cache, so it must be
qemuxml2xmltest. And that one should do *nothing* with any
capabilities. Merely because whatever it does must work without any
qemu installed in the system.
Thi
On Fri, Aug 07, 2015 at 04:39:43PM +0200, Michal Privoznik wrote:
This function should return the greatest CPU number set in
/domain/cpu/numa/cell/@cpus. The idea is that we should compare
the returned value against /domain/vcpu value. Yes, there exist
users who think the following is a good idea
https://bugzilla.redhat.com/show_bug.cgi?id=1176020
Some users think this is a good idea:
4
It's not. Lets therefore introduce a check and discourage them in
doing so.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf
On Fri, Aug 07, 2015 at 09:14:29AM -0400, John Ferlan wrote:
On 08/07/2015 06:44 AM, Martin Kletzander wrote:
On Tue, Aug 04, 2015 at 09:27:13PM -0400, John Ferlan wrote:
$SUBJ
s/pining/pinning
Or perhaps - "qemu: Use numad information when getting pin information""
OK, I won't mention a
This function should return the greatest CPU number set in
/domain/cpu/numa/cell/@cpus. The idea is that we should compare
the returned value against /domain/vcpu value. Yes, there exist
users who think the following is a good idea:
4
Signed-off-by: Michal Pri
On 08/07/2015 06:44 AM, Martin Kletzander wrote:
> On Tue, Aug 04, 2015 at 09:27:13PM -0400, John Ferlan wrote:
>> $SUBJ
>>
>> s/pining/pinning
>>
>> Or perhaps - "qemu: Use numad information when getting pin information""
>>
>
> OK, I won't mention anything pine-cone-related then ;)
>
>> On 07
Hello!
> The qemuxml2argvtest mocks the capability cache, so it must be
> qemuxml2xmltest. And that one should do *nothing* with any
> capabilities. Merely because whatever it does must work without any
> qemu installed in the system.
This is what happens if you remove the check:
--- cut ---
On Fri, Aug 07, 2015 at 12:06:06 +0200, Martin Kletzander wrote:
> On Fri, Aug 07, 2015 at 11:06:13AM +0200, Peter Krempa wrote:
> >Qemu reports physical size 0 for block devices. As 15fa84acbb55ebfee6a4
> >changed the behavior of qemuDomainGetBlockInfo to just query the monitor
> >this created a r
On Tue, Aug 04, 2015 at 09:27:13PM -0400, John Ferlan wrote:
$SUBJ
s/pining/pinning
Or perhaps - "qemu: Use numad information when getting pin information""
OK, I won't mention anything pine-cone-related then ;)
On 07/26/2015 12:57 PM, Martin Kletzander wrote:
Pinning information returned
On Fri, Aug 07, 2015 at 11:06:13AM +0200, Peter Krempa wrote:
Qemu reports physical size 0 for block devices. As 15fa84acbb55ebfee6a4
changed the behavior of qemuDomainGetBlockInfo to just query the monitor
this created a regression since we didn't report the size correctly any
more.
This patch
On 29.07.2015 18:28, Daniel P. Berrange wrote:
> On Mon, Jul 20, 2015 at 03:38:59PM +0200, Martin Kletzander wrote:
>> On Mon, Jul 20, 2015 at 11:23:02AM +0200, poma wrote:
>>>
>>> $ qemu-system-x86_64 ... -device virtio-vga
>>>
>>>
>>> # lspci -d 1af4:1050 -knn
>>> 00:03.0 VGA compatible controlle
Qemu reports physical size 0 for block devices. As 15fa84acbb55ebfee6a4
changed the behavior of qemuDomainGetBlockInfo to just query the monitor
this created a regression since we didn't report the size correctly any
more.
This patch adds code to refresh the physical size of a block device by
open
On Tue, Aug 04, 2015 at 11:38:09 +0200, Andrea Bolognani wrote:
> New test cases cover the cpuCompare() and cpuBaseline() implementation.
> ---
> tests/cputest.c | 10 ++
> tests/cputestdata/ppc64-baseline-incompatible-models.xml | 14 ++
Hi Laine,
I'm sorry for starting 3 threads with the same topic, seems like my mail
was heavily delayed yesterday.
[ removing personal mail ]
Op 8/7/2015 om 12:24 AM schreef Laine Stump:
Subject: Reproducible live disk detach bug
Hey guys,
I am currently running into a reproducible libvirt
On Tue, Aug 04, 2015 at 11:38:08 +0200, Andrea Bolognani wrote:
> This is yet another variation of POWER8. The PVR information comes
> from arch/powerpc/kernel/cputable.c in the Linux kernel tree.
> ---
> src/cpu/cpu_map.xml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/cpu/cpu_map
On Fri, Aug 07, 2015 at 09:32:56AM +0300, Pavel Fedin wrote:
Hello!
>So every ARM qemu with the "virt" machine type supports both PCI and
>multiqueue?
Every ARM qemu with "virt" machine AND pci-generic supports them.
How about those "virt-*" for which you check below. That
>might not be
48 matches
Mail list logo
