[libvirt] [jenkins-ci PATCH 0/2] git changes to reflect new CI configuration
by Pavel Hrdina
Pavel Hrdina (2):
jobs: Change git URL to github
jobs: Switch to github webhook instead of polling
jobs/autotools.yaml | 5 ++---
jobs/generic.yaml | 5 ++---
jobs/go.yaml | 5 ++---
jobs/perl-modulebuild.yaml | 5 ++---
jobs/python-distutils.yaml | 5 ++---
5 files changed, 10 insertions(+), 15 deletions(-)
--
2.17.1
6 years, 5 months
[libvirt] [PATCH] cpu: add 'amd-ssbd' and 'amd-no-ssb' CPU features (CVE-2018-3639)
by Daniel P. Berrangé
AMD x86 CPUs have two separate ways to mitigate the Speculative Store
Bypass hardware flaw. In current processors only non-architectural MSRs
are available, and so hypervisors must expose a virtualized MSR and CPU
flag "virt-ssbd" (CPUID Function 8000_0008, EBX[25]=1).
In future processors AMD will provide an architectural MSR, indicated by
existance of the CPUID Function 8000_0008, EBX[24]=1, to which QEMU has
given the name "amd-ssbd".
The "amd-ssbd" flag should be used in preference to "virt-ssbd", if it
is available, since it provides improved performance. For virtual
machine configuration, both should be exposed when available, to allow
for maximal guest OS compatibility as not all guests yet support both.
If future processes are not vulnerable to the flaw, this will be
indicated by the existance of CPUID Function 8000_0008, EBX[26]=1,
to which QEMU has given the name "amd-no-ssb".
See also 124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
from:
https://bugzilla.kernel.org/show_bug.cgi?id=199889
Note that neither amd-ssbd or amd-no-ssb will be reported by the kernel
in /proc/cpuinfo. It knows about these CPUID bits and does the right thing,
but doesn't report their existance as distinct flags in /proc/cpuinfo.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/cpu/cpu_map.xml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
index 96daa0f9af..9af190a579 100644
--- a/src/cpu/cpu_map.xml
+++ b/src/cpu/cpu_map.xml
@@ -433,9 +433,15 @@
<feature name='ibpb'>
<cpuid eax_in='0x80000008' ebx='0x00001000'/>
</feature>
+ <feature name='amd-ssbd'>
+ <cpuid eax_in='0x80000008' ebx='0x01000000'/>
+ </feature>
<feature name='virt-ssbd'>
<cpuid eax_in='0x80000008' ebx='0x02000000'/>
</feature>
+ <feature name='amd-no-ssb'>
+ <cpuid eax_in='0x80000008' ebx='0x04000000'/>
+ </feature>
<!-- models -->
<model name='486'>
--
2.17.0
6 years, 5 months
[libvirt] [PATCH 0/1] *** SUBJECT HERE ***
by Han Han
*** BLURB HERE ***
Han Han (1):
docs: schema: Add missing <interleave> to devices
docs/schemas/domaincommon.rng | 60 +++++++++++++++++++----------------
1 file changed, 33 insertions(+), 27 deletions(-)
--
2.17.1
6 years, 5 months
[libvirt] [PATCH] schema: allow a <rule> element with no subelements in a nwfilter
by Laine Stump
This is a regression in behavior caused by commit 37359814. It was
intended to limit the schema to allow only a single subelement of
<rule>, but it is also acceptable for <rule> to have no subelement at
all.
To prevent the same error from reoccurring in the future, the
examples/xml/nwfilter directory was added to the list of nwfilter
schema test directories.
Resolves: https://bugzilla.redhat.com/1593549
Signed-off-by: Laine Stump <laine(a)laine.org>
---
docs/schemas/nwfilter.rng | 1 +
tests/virschematest.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/schemas/nwfilter.rng b/docs/schemas/nwfilter.rng
index cca6ff2954..17cda5c78d 100644
--- a/docs/schemas/nwfilter.rng
+++ b/docs/schemas/nwfilter.rng
@@ -20,6 +20,7 @@
<element name="rule">
<ref name="rule-node-attributes"/>
<choice>
+ <empty/>
<element name="mac">
<ref name="match-attribute"/>
<ref name="common-l2-attributes"/>
diff --git a/tests/virschematest.c b/tests/virschematest.c
index 2d35833919..aa65a434ff 100644
--- a/tests/virschematest.c
+++ b/tests/virschematest.c
@@ -229,7 +229,7 @@ mymain(void)
DO_TEST_DIR("network.rng", "../src/network", "networkxml2xmlin",
"networkxml2xmlout", "networkxml2confdata");
DO_TEST_DIR("nodedev.rng", "nodedevschemadata");
- DO_TEST_DIR("nwfilter.rng", "nwfilterxml2xmlout");
+ DO_TEST_DIR("nwfilter.rng", "nwfilterxml2xmlout", "../examples/xml/nwfilter");
DO_TEST_DIR("secret.rng", "secretxml2xmlin");
DO_TEST_DIR("storagepool.rng", "storagepoolxml2xmlin", "storagepoolxml2xmlout",
"storagepoolschemadata");
--
2.14.4
6 years, 5 months
[libvirt] [PATCH 0/2] Two small problems with hyperv Makefile
by Laine Stump
I found these when make failed after running "make maintainer-clean".
Laine Stump (2):
hyperv: fix typo in Makefile.am.inc
hyperv: erase "generated files" sentinel during make maintainer-clean
src/hyperv/Makefile.inc.am | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.14.4
6 years, 5 months
[libvirt] [dbus PATCH 0/3] tests: Some fixes and cleanups
by Andrea Bolognani
The first patch fixes an actual bug, the rest just makes
things a bit nicer.
Andrea Bolognani (3):
tests: Fix VIRT_DBUS_INTERFACES_DIR
tests: Don't loop up abs_top_builddir in the environment
tests: Use AM_TESTS_ENVIRONMENT
tests/Makefile.am | 5 ++---
tests/libvirttest.py | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
--
2.17.1
6 years, 5 months
Re: [libvirt] [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine
by Eduardo Habkost
Getting back to this discussion:
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > Add to that shortcuts like -cdrom
> > > > stop working,
> > >
> > > Maybe is fixable.
> >
> > Already fixed for ages.
> >
> > > I see marking Q35 as the default machine a first step.
> >
> > Maybe the better option is to go the arm route: Just don't define a
> > default, so users have to specify pc or q35. That will make them notice
> > there is a world beside 'pc', and we also avoid breaking things
> > silently.
>
> If QEMU removes the default, then libvirt will have to hardcode
> 'pc' as the default to maintain back compatibility, so I don't
> think that ends up as a net win
I believe there's consensus that applications blindly relying on
the default machine-type when creating a domain is a bad idea.
That said, can we deprecate this feature in libvirt, encourage
applications to always specify an explicit machine-type, thus
making it possible to deprecate the i440fx machine-types one day?
--
Eduardo
6 years, 5 months
[libvirt] [PATCH 0/3] some small fix for guest SEV related code
by Luyao Huang
*** BLURB HERE ***
Luyao Huang (3):
qemu: correct the ret value
qemu: improve the debug message when preparing SEV guest
docs: remove extra space in the SEV xml element example
docs/formatdomain.html.in | 10 +++++-----
src/qemu/qemu_process.c | 3 ++-
2 files changed, 7 insertions(+), 6 deletions(-)
--
1.8.3.1
6 years, 5 months
Re: [libvirt] [Qemu-devel] [PATCH] hw/i386: Deprecate the machine types pc-0.10 and pc-0.11
by Eduardo Habkost
(CCing Markus and libvir-list)
On Wed, Jun 20, 2018 at 08:40:38PM +0200, Thomas Huth wrote:
> On 12.06.2018 00:18, Eduardo Habkost wrote:
> > On Mon, Jun 11, 2018 at 05:41:04AM +0200, Thomas Huth wrote:
> >> The oldest machine type which is still used in a maintained distribution
> >> is a pc-0.12 based machine type in RHEL6, so everything that is older
> >> than pc-0.12 should not be used anymore. Thus let's deprecate pc-0.10
> >> and pc-0.11 so that we can finally remove them in a future release.
> [...]
> >> @@ -3952,6 +3953,10 @@ int main(int argc, char **argv, char **envp)
> >> }
> >>
> >> machine_class = select_machine();
> >> + if (machine_class->deprecation_msg) {
> >> + error_report("Machine type '%s' is deprecated: %s",
> >> + machine_class->name, machine_class->deprecation_msg);
> >> + }
> >
> > Do you plan to add this info to 'query-machines' QMP command?
>
> No, I'm not planning to add this. We'd need a request from upper layers
> (i.e. libvirt) for this first, otherwise it's just a dead interface that
> nobody is using.
I believe that useful information being available only through
stderr is at least as bad as being available only through HMP.
Should we extend QMP more proactively in cases like this, too?
(In either case, I don't think this should block your series)
--
Eduardo
6 years, 5 months
