[libvirt] [PATCH] Clarify lack of generated IDE -device string in QEMU driver
The QEMU driver contained code to generate a -device string for piix4-ide, but
wasn't using it. This was intentional. This change removes the string generation
and adds a comment explaining why no -device is necessary.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Add comments.
---
src/qemu/qemu_conf.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..1c4f326 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,19 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+/* We don't add an explicit IDE controller because the provided
+ * PIIX4 device already includes one. It isn't possible to remove
+ * the PIIX4. */
+if (def-controllers[i]-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE)
continue;
ADD_ARG_LIT(-device);
-if (!(scsi = qemuBuildControllerDevStr(def-controllers[i])))
+char *devstr;
+if (!(devstr = qemuBuildControllerDevStr(def-controllers[i])))
goto no_memory;
-ADD_ARG(scsi);
+ADD_ARG(devstr);
}
}
--
1.6.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Clarify lack of generated IDE -device string in QEMU driver
On Thu, Jan 28, 2010 at 10:35:48AM +, Matthew Booth wrote:
The QEMU driver contained code to generate a -device string for piix4-ide, but
wasn't using it. This was intentional. This change removes the string
generation
and adds a comment explaining why no -device is necessary.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Add comments.
---
src/qemu/qemu_conf.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..1c4f326 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr
def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,19 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+/* We don't add an explicit IDE controller because the provided
+ * PIIX4 device already includes one. It isn't possible to remove
+ * the PIIX4. */
+if (def-controllers[i]-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE)
continue;
That's not quite right because you changed the conditional to blacklist IDE
insteasd of whitelisting SCSI. This means that FDC now falls through. We do
not need to explicitly add the FDC, since that is also provided automatically
on the ISA bridge that's behind the PIIX4.
ADD_ARG_LIT(-device);
-if (!(scsi = qemuBuildControllerDevStr(def-controllers[i])))
+char *devstr;
+if (!(devstr = qemuBuildControllerDevStr(def-controllers[i])))
goto no_memory;
-ADD_ARG(scsi);
+ADD_ARG(devstr);
}
}
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Clarify lack of generated IDE -device string in QEMU driver
On 28/01/10 10:57, Daniel P. Berrange wrote:
On Thu, Jan 28, 2010 at 10:35:48AM +, Matthew Booth wrote:
The QEMU driver contained code to generate a -device string for piix4-ide,
but
wasn't using it. This was intentional. This change removes the string
generation
and adds a comment explaining why no -device is necessary.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Add comments.
---
src/qemu/qemu_conf.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..1c4f326 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr
def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,19 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type !=
VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+/* We don't add an explicit IDE controller because the provided
+ * PIIX4 device already includes one. It isn't possible to
remove
+ * the PIIX4. */
+if (def-controllers[i]-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE)
continue;
That's not quite right because you changed the conditional to blacklist IDE
insteasd of whitelisting SCSI. This means that FDC now falls through. We do
not need to explicitly add the FDC, since that is also provided automatically
on the ISA bridge that's behind the PIIX4.
Ok. Still think a blacklist is more appropriate, though. I'll add FDC to
the blacklist. Are there any more?
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Clarify why some controllers don't generate -device string in QEMU driver
The QEMU driver contained code to generate a -device string for piix4-ide, but
wasn't using it. This change removes this string generation. It also adds a
comment explaining why IDE and FDC controllers don't generate -device strings.
The change also generates an error if a sata controller is specified for a QEMU
domain, as this isn't supported.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Ignore IDE and FDC
controllers. Error if SATA controller is discovered. Add
comments.
---
src/qemu/qemu_conf.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..1c4f326 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,19 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+/* We don't add an explicit IDE controller because the provided
+ * PIIX4 device already includes one. It isn't possible to remove
+ * the PIIX4. */
+if (def-controllers[i]-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE)
continue;
ADD_ARG_LIT(-device);
-if (!(scsi = qemuBuildControllerDevStr(def-controllers[i])))
+char *devstr;
+if (!(devstr = qemuBuildControllerDevStr(def-controllers[i])))
goto no_memory;
-ADD_ARG(scsi);
+ADD_ARG(devstr);
}
}
--
1.6.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] util.c (virGetUserEnt): don't use a negative value as allocation size
Not a big deal, but reporting a failed sysconf call will make
this far easier to diagnose than reporting an unwarranted OOM.
From 2bf48c9414cac791f03228ff15590414ec617f22 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 28 Jan 2010 13:37:05 +0100
Subject: [PATCH] util.c (virGetUserEnt): don't use a negative value as
allocation size
* src/util/util.c (virGetUserEnt): In the unlikely event that
sysconf(_SC_GETPW_R_SIZE_MAX) fails, don't use -1 as the size in
the subsequent allocation.
---
src/util/util.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/util/util.c b/src/util/util.c
index 0ce5026..701581d 100644
--- a/src/util/util.c
+++ b/src/util/util.c
@@ -2317,7 +2317,13 @@ static char *virGetUserEnt(virConnectPtr conn,
char *ret;
struct passwd pwbuf;
struct passwd *pw = NULL;
-size_t strbuflen = sysconf(_SC_GETPW_R_SIZE_MAX);
+long val = sysconf(_SC_GETPW_R_SIZE_MAX);
+size_t strbuflen = val;
+
+if (val 0) {
+virReportSystemError(conn, errno, %s, _(sysconf failed));
+return NULL;
+}
if (VIR_ALLOC_N(strbuf, strbuflen) 0) {
virReportOOMError(conn);
--
1.7.0.rc0.170.g7207c
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt: build error
Hi, I'm getting the following error when I make libvirt version 0.7.4 Make all-recursive make[1]: Entering directory `/home/sharadhap/libvirt-0.7.4' Making all in gnulib/lib make[2]: Entering directory `/home/sharadhap/libvirt-0.7.4/gnulib/lib' make all-recursive make[3]: Entering directory `/home/sharadhap/libvirt-0.7.4/gnulib/lib' make[4]: Entering directory `/home/sharadhap/libvirt-0.7.4/gnulib/lib' /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -g -O2 -MT printf-parse.lo -MD -MP -MF .deps/printf-parse.Tpo -c -o printf-parse.lo printf-parse.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -g -O2 -MT printf-parse.lo -MD -MP -MF .deps/printf-parse.Tpo -c printf-parse.c -fPIC -DPIC -o .libs/printf-parse.o In file included from printf-parse.c:70: xsize.h: In function 'xsum': xsize.h:59: error: expected expression before ')' token xsize.h:59: error: expected expression before ')' token printf-parse.c: In function 'printf_parse': printf-parse.c:164: error: expected expression before ')' token printf-parse.c:164: error: expected expression before ')' token printf-parse.c:164: error: expected expression before ')' token printf-parse.c:164: error: expected expression before ')' token printf-parse.c:168: error: expected expression before ')' token printf-parse.c:168: error: expected expression before ')' token printf-parse.c:234: error: expected expression before ')' token printf-parse.c:234: error: expected expression before ')' token printf-parse.c:234: error: expected expression before ')' token printf-parse.c:234: error: expected expression before ')' token printf-parse.c:238: error: expected expression before ')' token printf-parse.c:238: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:252: error: expected expression before ')' token printf-parse.c:291: error: expected expression before ')' token printf-parse.c:291: error: expected expression before ')' token printf-parse.c:291: error: expected expression before ')' token printf-parse.c:291: error: expected expression before ')' token printf-parse.c:295: error: expected expression before ')' token printf-parse.c:295: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:310: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:567: error: expected expression before ')' token printf-parse.c:579: error: expected expression before ')' token printf-parse.c:579: error: expected expression before ')' token printf-parse.c:579: error: expected expression before ')' token printf-parse.c:579: error: expected expression before ')' token printf-parse.c:580: error: expected expression before ')' token printf-parse.c:580: error: expected expression before ')' token printf-parse.c:580: error: expected expression before ')' token printf-parse.c:580: error: expected expression before ')' token printf-parse.c:581: error: expected expression before ')' token printf-parse.c:581: error: expected expression before ')' token make[4]: *** [printf-parse.lo] Error 1 make[4]: Leaving directory `/home/sharadhap/libvirt-0.7.4/gnulib/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/sharadhap/libvirt-0.7.4/gnulib/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory
[libvirt] [PATCH] Clarify why some controllers don't generate -device string in QEMU driver
The QEMU driver contained code to generate a -device string for piix4-ide, but
wasn't using it. This change removes this string generation. It also adds a
comment explaining why IDE and FDC controllers don't generate -device strings.
The change also generates an error if a sata controller is specified for a QEMU
domain, as this isn't supported.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Ignore IDE and FDC
controllers. Error if SATA controller is discovered. Add
comments.
---
src/qemu/qemu_conf.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..3b7793f 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,29 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+virDomainControllerDefPtr cont = def-controllers[i];
+
+/* We don't add an explicit IDE or FD controller because the
+ * provided PIIX4 device already includes one. It isn't possible to
+ * remove the PIIX4. */
+if (cont-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE ||
+cont-type == VIR_DOMAIN_CONTROLLER_TYPE_FDC)
continue;
+/* QEMU doesn't implement a SATA driver */
+if (cont-type == VIR_DOMAIN_CONTROLLER_TYPE_SATA) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT,
+ %s, _(SATA is not supported with this QEMU
binary));
+goto error;
+}
+
ADD_ARG_LIT(-device);
-if (!(scsi = qemuBuildControllerDevStr(def-controllers[i])))
+char *devstr;
+if (!(devstr = qemuBuildControllerDevStr(def-controllers[i])))
goto no_memory;
-ADD_ARG(scsi);
+ADD_ARG(devstr);
}
}
--
1.6.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Clarify why some controllers don't generate -device string in QEMU driver
On Thu, Jan 28, 2010 at 12:53:56PM +, Matthew Booth wrote:
The QEMU driver contained code to generate a -device string for piix4-ide, but
wasn't using it. This change removes this string generation. It also adds a
comment explaining why IDE and FDC controllers don't generate -device strings.
The change also generates an error if a sata controller is specified for a
QEMU
domain, as this isn't supported.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Ignore IDE and FDC
controllers. Error if SATA controller is discovered.
Add
comments.
---
src/qemu/qemu_conf.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..3b7793f 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr
def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,29 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+virDomainControllerDefPtr cont = def-controllers[i];
+
+/* We don't add an explicit IDE or FD controller because the
+ * provided PIIX4 device already includes one. It isn't possible
to
+ * remove the PIIX4. */
+if (cont-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE ||
+cont-type == VIR_DOMAIN_CONTROLLER_TYPE_FDC)
continue;
+/* QEMU doesn't implement a SATA driver */
+if (cont-type == VIR_DOMAIN_CONTROLLER_TYPE_SATA) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT,
+ %s, _(SATA is not supported with this
QEMU binary));
+goto error;
+}
+
ADD_ARG_LIT(-device);
-if (!(scsi = qemuBuildControllerDevStr(def-controllers[i])))
+char *devstr;
+if (!(devstr = qemuBuildControllerDevStr(def-controllers[i])))
goto no_memory;
-ADD_ARG(scsi);
+ADD_ARG(devstr);
}
}
ACK, looks fine now
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Libvirt/LXC creation example
Hi, I am looking for a simple example for creating a Linux container (LXC) with a network connection that can be accessed from the outside world. I first tried to set up a bridge and link it with the interface eth0 configured on host via: brctl addif virbr0 eth0 but each time I did that - I lost the connection to the host and could not even ping it. The connection was resumed only when removing the host interface of eth0 from the bridge: brctl delif virbr0 eth0 How can I define the network interfaces to be configured inside the container? How can I setup container IPs? Any full XML example would be appreciated. Thanks - Avi -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Allow a per-PCI passthrough device permissive attribute
On 01/27/2010 01:49 PM, Daniel P. Berrange wrote: On Wed, Jan 27, 2010 at 09:23:52AM -0500, Chris Lalancette wrote: Currently there is a global tag to let the administrator turn off system-wide ACS checking when doing PCI device passthrough. However, this is too coarse-grained of an attribute, since it doesn't allow setups where certain guests are trusted while other ones are untrusted. Allow more complicated setups by making the device checking a per-device setting. The more detailed explanation of why this is necessary delves deep into PCIe internals. Ideally we'd like to be able to probe devices and figure out whether it is safe to assign them. In practice, this isn't possible because PCIe allows devices to have hidden bridges that software can't discover. If you were to have two devices assigned to two different domains behind one of these hidden bridges, they could do P2P traffic and bypass all of the VT-d/IOMMU checks. The next thing we could try to do is to have a whitelist of devices that we know to be safe. For instance, instead of a hidden bridge, PCI devices can multiplex functions instead, which causes all traffic to head to an upstream bridge before P2P can take place. Additionally, some hidden PCI bridges may have ACS on-board. In both of these cases it's safe to passthrough the device(s), since they can't P2P without the IOMMU getting involved. However, even if we did have a whitelist, I think we still need a permissive attribute. For one thing, the whitelist will always be out of date with respect to new hardware, so we'd need to allow administrators to temporarily override the whitelist restriction until a new version of the whitelist came out. Also, we want to support the case where the administrator knows it is safe to assign possibly unsafe devices to a domain he trusts. A domain is only trusted until its guest OS gets exploited at which point this proposed change may let it escape into the host. If you don't have any IOMMU on your host, you can't use PCI device assignment with KVM at all, because it would not be safe in the event of guest exploit / mis- behavior. The same is true of device assignment in this non-ACS + hidden bridge case. While this is true, I don't think this is the sort of policy we should be enforcing in libvirt. Witness the users who still use Xen PV PCI passthrough, despite the fact that is unsafe. We still support them. If KVM had the ability to do non-IOMMU passthrough, I would think we would want to allow that usage through libvirt. Should we be safe by default? Absolutely. But should we give administrators enough rope to hang themselves? Yes, it's the Unix way. Thus I don't see why we should introduce a special permissive flag solely for the non-ACS edge case, while at the smae time not allowing the same permissiveness for the far more common non-IOMMU case. NB, I'm not suggesting we allow skipping of the checks for the non-IOMMU case either. Keeping a whitelist of devices up2date wrt new hardware launches is no more troublesome than the existing problem of updating the PCI-IDs databse or actually providing updated kernel releases with new drivers. If we use the permissive attribute, then every admin with a device that is known to be safe has the pain of setting the permissive attribute, every time, on every machine with this hardware. If we have a whitelist, then 99% of the time everything will just work because it will already be known to the whitelist. If the whitelist were an external datafile the admin could even extend it in the rare occasion when a new device were not known. This is a choice of make everyone solve over over again themselves, or solve it once for everybody. I don't really like the idea of a whitelist, but I like it more than just pushing the problem onto admins via per guest flags. For that matter I don't like the host level flag we have either and would rather we removed it. If only there's a 3rd way that were neither flags or whitelists ... The problem that I tried (and failed) to explain in the commit message is that even with a whitelist, it is not sufficient. The problem is that with multi-function PCI devices, software cannot tell whether it is possible to do P2P traffic. In the case that a manufacturer tells us no, our device doesn't allow P2P traffic, then great, we can add it to the whitelist. But if a manufacturer can't or won't tell us that, then we have to assume it can do P2P traffic, and block it. But these multi-function PCI devices are *exactly* the devices we want to passthrough to guests (all multi-port NICs we have tested are multi-function). So even with the whitelist, you still have to leave a way for the admin to override the check. -- Chris Lalancette -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirt guide draft published on libvirt.org
On Mon, 2010-01-18 at 20:00 -0500, David Jorm wrote:
I am a tech writer who recently joined the Red Hat team. I have been tasked
with assisting in the improvement of libvirt documentation where possible and
co-ordinating the development of the libvirt Application Development Guide.
The guide was previously in the hands of Dani Coulson, who has since left Red
Hat. She got it to a draft stage with a skeletal structure, but as far as I
can tell nothing ever reached a publishable state. I've picked up where she
left off and re-built the latest guide from the DocBook XML in git. It is now
up at:
http://libvirt.org/guide/
If you look in the guide, you will notice an awful lot of TBD stubs.
Contributions to fill these would be greatly appreciated - please email them
to me directly. I will chase up with the people who were originally nominated
as the responsible parties to try and get some content to flesh out the guide.
I don't have a lot of spare temporal bandwidth at the moment, but if there
are any docs-related BZs or libvirt issues, feel free to push them my way and
i'll do what I can. I think i've made every mistake possible so far in
submitting patches, so I know the process by virtue of what-not-to-do.
Thanks
David
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
A few minor spelling problems which I noticed:
diff --git a/en-US/Network_Interfaces.xml b/en-US/Network_Interfaces.xml
index c307dc6..cc45cf0 100644
--- a/en-US/Network_Interfaces.xml
+++ b/en-US/Network_Interfaces.xml
@@ -14,7 +14,7 @@
para
The configuration of network interfaces on physical hosts can be
examined and modified with functions in the virInterface API.
This is
- useful for setting up the host to share one physical interface
bewteen
+ useful for setting up the host to share one physical interface
between
multiple guest domains you want connected directly to the network
(briefly - enslave a physical interface to the bridge, then
create a
tap device for each VM you want to share the interface), as well
as
@@ -332,7 +332,7 @@ free(xml);]]
/para
section
id=Application_Development_Guide-Network_Interfaces-Configs-Define
- titleDefining an inteface configuration/title
+ titleDefining an interface configuration/title
para
The virInterfaceDefineXML function is used both for adding new
interface configurations
and modifying existing configurations. It either adds a new
interface
@@ -382,7 +382,7 @@ cleanup:
/section
section
id=Application_Development_Guide-Network_Interfaces-Configs-Undefine
- titleUndefining an inteface configuration/title
+ titleUndefining an interface configuration/title
para
virInterfaceUndefine completely and permanently removes the
configuration for the given interface from tho host's
configuration
@@ -442,7 +442,7 @@ if (!iface) {
para
virInterfaceDestroy makes the given interface inactive (down).
On
success, it returns 0. If there is any problem making the
interface
- acrive, -1 is returned.
+ active, -1 is returned.
/para
example
--
Best regards,
Gerhard Stenzel,
---
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] Add QEMU support for virtio channel
Support virtio-serial controller and virtio channel in QEMU backend. Will output
the following for virtio-serial controller:
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4
and the following for a virtio channel:
-chardev pty,id=channel0 \
-device virtserialport,chardev=channel0,name=org.linux-kvm.port.0
* src/qemu/qemu_conf.c: Add argument output for virtio
* tests/qemuxml2argvtest.c
tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
: Add test for QEMU command line generation
---
src/qemu/qemu_conf.c | 51 +++-
.../qemuxml2argv-channel-virtio.args |1 +
tests/qemuxml2argvtest.c |1 +
3 files changed, 52 insertions(+), 1 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 0c67334..73c6e28 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1681,7 +1681,6 @@ qemuAssignDevicePCISlots(virDomainDefPtr def)
}
for (i = 0; i def-nchannels ; i++) {
/* Nada - none are PCI based (yet) */
-/* XXX virtio-serial will need one */
}
if (def-watchdog) {
qemuAssignDevicePCISlot(def-watchdog-info, nextslot++);
@@ -2121,6 +2120,15 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+case VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL:
+if (def-info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) {
+virBufferAddLit(buf, virtio-serial-pci);
+} else {
+virBufferAddLit(buf, virtio-serial);
+}
+virBufferVSprintf(buf, ,id=virtio-serial%d, def-idx);
+break;
+
/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
default:
@@ -3508,6 +3516,47 @@ int qemudBuildCommandLine(virConnectPtr conn,
}
ADD_ARG(virBufferContentAndReset(buf));
+break;
+
+case VIR_DOMAIN_CHR_TARGET_TYPE_VIRTIO:
+if (!(qemuCmdFlags QEMUD_CMD_FLAG_DEVICE)) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT, %s,
+_(virtio channel requires QEMU to support -device));
+goto error;
+}
+
+qemudBuildCommandLineChrDevChardevStr(channel, buf);
+if (virBufferError(buf))
+goto error;
+
+ADD_ARG_LIT(-chardev);
+ADD_ARG(virBufferContentAndReset(buf));
+
+virBufferVSprintf(buf, virtserialport,chardev=%s,
+ channel-info.alias);
+if (channel-target.virtio.name) {
+virBufferVSprintf(buf, ,name=%s,
+ channel-target.virtio.name);
+}
+if (channel-target.virtio.byteLimit) {
+virBufferVSprintf(buf, ,byte_limit=%s,
+ channel-target.virtio.byteLimit);
+}
+if (channel-target.virtio.guestByteLimit) {
+virBufferVSprintf(buf, ,guest_byte_limit=%s,
+ channel-target.virtio.guestByteLimit);
+}
+if (channel-target.virtio.cacheBuffers) {
+virBufferVSprintf(buf, ,cache_buffers=%s,
+ channel-target.virtio.cacheBuffers);
+}
+if (virBufferError(buf))
+goto error;
+
+ADD_ARG_LIT(-device);
+ADD_ARG(virBufferContentAndReset(buf));
+
+break;
}
}
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
new file mode 100644
index 000..ded97d1
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
@@ -0,0 +1 @@
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M
pc -m 214 -smp 1 -nographic -nodefaults -monitor
unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -hda
/dev/HostVG/QEMUGuest1 -chardev pty,id=channel0 -device
virtserialport,chardev=channel0,name=org.linux-kvm.port.0,byte_limit=1048576,guest_byte_limit=1048576,cache_buffers=1
-usb -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index fc237c2..f6b33c2 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -297,6 +297,7 @@ mymain(int argc, char **argv)
DO_TEST(console-compat-chardev,
QEMUD_CMD_FLAG_CHARDEV|QEMUD_CMD_FLAG_DEVICE);
DO_TEST(channel-guestfwd, QEMUD_CMD_FLAG_CHARDEV|QEMUD_CMD_FLAG_DEVICE);
+DO_TEST(channel-virtio, QEMUD_CMD_FLAG_DEVICE);
DO_TEST(watchdog, 0);
DO_TEST(watchdog-device, QEMUD_CMD_FLAG_DEVICE);
--
1.6.6
--
libvir-list
[libvirt] [PATCH 1/3] Clarify why some controllers don't generate -device string in QEMU driver
The QEMU driver contained code to generate a -device string for piix4-ide, but
wasn't using it. This change removes this string generation. It also adds a
comment explaining why IDE and FDC controllers don't generate -device strings.
The change also generates an error if a sata controller is specified for a QEMU
domain, as this isn't supported.
* src/qemu/qemu_conf.c: Remove VIR_DOMAIN_CONTROLLER_TYPE_IDE handler in
qemuBuildControllerDevStr(). Ignore IDE and FDC
controllers. Error if SATA controller is discovered. Add
comments.
---
src/qemu/qemu_conf.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f4a6c08..3b7793f 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -2121,11 +2121,8 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
-virBufferAddLit(buf, piix4-ide);
-virBufferVSprintf(buf, ,id=ide%d, def-idx);
-break;
-
default:
goto error;
}
@@ -3141,16 +3138,29 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (qemuCmdFlags QEMUD_CMD_FLAG_DEVICE) {
for (i = 0 ; i def-ncontrollers ; i++) {
-char *scsi;
-if (def-controllers[i]-type != VIR_DOMAIN_CONTROLLER_TYPE_SCSI)
+virDomainControllerDefPtr cont = def-controllers[i];
+
+/* We don't add an explicit IDE or FD controller because the
+ * provided PIIX4 device already includes one. It isn't possible to
+ * remove the PIIX4. */
+if (cont-type == VIR_DOMAIN_CONTROLLER_TYPE_IDE ||
+cont-type == VIR_DOMAIN_CONTROLLER_TYPE_FDC)
continue;
+/* QEMU doesn't implement a SATA driver */
+if (cont-type == VIR_DOMAIN_CONTROLLER_TYPE_SATA) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT,
+ %s, _(SATA is not supported with this QEMU
binary));
+goto error;
+}
+
ADD_ARG_LIT(-device);
-if (!(scsi = qemuBuildControllerDevStr(def-controllers[i])))
+char *devstr;
+if (!(devstr = qemuBuildControllerDevStr(def-controllers[i])))
goto no_memory;
-ADD_ARG(scsi);
+ADD_ARG(devstr);
}
}
--
1.6.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3] Add domain support for virtio channel
Add support for virtio-serial by defining a new 'virtio' channel target type and
a virtio-serial controller. Allows the following to be specified in a domain:
controller type='virtio-serial' index='0'/
channel type='pty'
target type='virtio' name='org.linux-kvm.port.0'/
/channel
* docs/schemas/domain.rng: Add virtio-serial controller and virtio channel type.
* src/conf/domain_conf.[ch]: Domain parsing/serialization for virtio-serial
controller and virtio channel.
* tests/qemuxml2xmltest.c
tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.xml
: add domain xml parsing test
* src/libvirt_private.syms
src/qemu/qemu_conf.c: virDomainDefAddDiskControllers() renamed to
virDomainDefAddImplicitControllers()
---
docs/schemas/domain.rng| 25 -
src/conf/domain_conf.c | 124 +---
src/conf/domain_conf.h | 10 ++-
src/libvirt_private.syms |2 +-
src/qemu/qemu_conf.c |2 +-
.../qemuxml2argv-channel-virtio.xml| 28 +
tests/qemuxml2xmltest.c|1 +
7 files changed, 173 insertions(+), 19 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.xml
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index 827ff6f..a3247b9 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -530,6 +530,7 @@
valueide/value
valuescsi/value
valuesata/value
+valuevirtio-serial/value
/choice
/attribute
/optional
@@ -1120,12 +1121,34 @@
attribute name=port/
/element
/define
+ define name=virtioTarget
+element name=target
+ attribute name=type
+ valuevirtio/value
+ /attribute
+ optional
+attribute name=name/
+ /optional
+ optional
+attribute name=bytelimit/
+ /optional
+ optional
+attribute name=guestbytelimit/
+ /optional
+ optional
+attribute name=cachebuffers/
+ /optional
+/element
+ /define
define name=channel
element name=channel
ref name=qemucdevSrcType/
interleave
ref name=qemucdevSrcDef/
-ref name=guestfwdTarget/
+choice
+ ref name=guestfwdTarget/
+ ref name=virtioTarget/
+/choice
optional
ref name=address/
/optional
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e548d1d..3b96086 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -124,7 +124,8 @@ VIR_ENUM_IMPL(virDomainController,
VIR_DOMAIN_CONTROLLER_TYPE_LAST,
ide,
fdc,
scsi,
- sata)
+ sata,
+ virtio-serial)
VIR_ENUM_IMPL(virDomainFS, VIR_DOMAIN_FS_TYPE_LAST,
mount,
@@ -148,7 +149,8 @@ VIR_ENUM_IMPL(virDomainChrTarget,
VIR_DOMAIN_CHR_TARGET_TYPE_LAST,
parallel,
serial,
console,
- guestfwd)
+ guestfwd,
+ virtio)
VIR_ENUM_IMPL(virDomainChr, VIR_DOMAIN_CHR_TYPE_LAST,
null,
@@ -449,6 +451,13 @@ void virDomainChrDefFree(virDomainChrDefPtr def)
case VIR_DOMAIN_CHR_TARGET_TYPE_GUESTFWD:
VIR_FREE(def-target.addr);
break;
+
+case VIR_DOMAIN_CHR_TARGET_TYPE_VIRTIO:
+VIR_FREE(def-target.virtio.name);
+VIR_FREE(def-target.virtio.byteLimit);
+VIR_FREE(def-target.virtio.guestByteLimit);
+VIR_FREE(def-target.virtio.cacheBuffers);
+break;
}
switch (def-type) {
@@ -1460,7 +1469,7 @@ virDomainControllerDefParseXML(virConnectPtr conn,
type = virXMLPropString(node, type);
if (type) {
-if ((def-type = virDomainDiskBusTypeFromString(type)) 0) {
+if ((def-type = virDomainControllerTypeFromString(type)) 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_(unknown disk controller type '%s'), type);
goto error;
@@ -2081,6 +2090,48 @@ virDomainChrDefParseXML(virConnectPtr conn,
virSocketSetPort(def-target.addr, port);
break;
+case VIR_DOMAIN_CHR_TARGET_TYPE_VIRTIO:
+def-target.virtio.name
+= virXMLPropString(cur, name);
+def-target.virtio.byteLimit
+= virXMLPropString(cur, bytelimit);
+def-target.virtio.guestByteLimit
+= virXMLPropString(cur, guestbytelimit);
+def-target.virtio.cacheBuffers
+= virXMLPropString(cur, cachebuffers);
+
+/* Ensure bytelimit and guestbytelimit are positive
integers
+
[libvirt] [PATCH 2/2] Add QEMU support for virtio channel
Support virtio-serial controller and virtio channel in QEMU backend. Will output
the following for virtio-serial controller:
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4
and the following for a virtio channel:
-chardev pty,id=channel0 \
-device virtserialport,chardev=channel0,name=org.linux-kvm.port.0
* src/qemu/qemu_conf.c: Add argument output for virtio
* tests/qemuxml2argvtest.c
tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
: Add test for QEMU command line generation
---
src/qemu/qemu_conf.c | 38 +++-
.../qemuxml2argv-channel-virtio.args |1 +
tests/qemuxml2argvtest.c |1 +
3 files changed, 39 insertions(+), 1 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 0c67334..7123827 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1681,7 +1681,6 @@ qemuAssignDevicePCISlots(virDomainDefPtr def)
}
for (i = 0; i def-nchannels ; i++) {
/* Nada - none are PCI based (yet) */
-/* XXX virtio-serial will need one */
}
if (def-watchdog) {
qemuAssignDevicePCISlot(def-watchdog-info, nextslot++);
@@ -2121,6 +2120,15 @@ qemuBuildControllerDevStr(virDomainControllerDefPtr def)
virBufferVSprintf(buf, ,id=scsi%d, def-idx);
break;
+case VIR_DOMAIN_CONTROLLER_TYPE_VIRTIO_SERIAL:
+if (def-info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) {
+virBufferAddLit(buf, virtio-serial-pci);
+} else {
+virBufferAddLit(buf, virtio-serial);
+}
+virBufferVSprintf(buf, ,id=virtio-serial%d, def-idx);
+break;
+
/* We always get an IDE controller, whether we want it or not. */
case VIR_DOMAIN_CONTROLLER_TYPE_IDE:
default:
@@ -3508,6 +3516,34 @@ int qemudBuildCommandLine(virConnectPtr conn,
}
ADD_ARG(virBufferContentAndReset(buf));
+break;
+
+case VIR_DOMAIN_CHR_TARGET_TYPE_VIRTIO:
+if (!(qemuCmdFlags QEMUD_CMD_FLAG_DEVICE)) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT, %s,
+_(virtio channel requires QEMU to support -device));
+goto error;
+}
+
+qemudBuildCommandLineChrDevChardevStr(channel, buf);
+if (virBufferError(buf))
+goto error;
+
+ADD_ARG_LIT(-chardev);
+ADD_ARG(virBufferContentAndReset(buf));
+
+virBufferVSprintf(buf, virtserialport,chardev=%s,
+ channel-info.alias);
+if (channel-target.name) {
+virBufferVSprintf(buf, ,name=%s, channel-target.name);
+}
+if (virBufferError(buf))
+goto error;
+
+ADD_ARG_LIT(-device);
+ADD_ARG(virBufferContentAndReset(buf));
+
+break;
}
}
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
new file mode 100644
index 000..6cb2a8f
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.args
@@ -0,0 +1 @@
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M
pc -m 214 -smp 1 -nographic -nodefaults -monitor
unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -hda
/dev/HostVG/QEMUGuest1 -chardev pty,id=channel0 -device
virtserialport,chardev=channel0,name=org.linux-kvm.port.0 -usb -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index fc237c2..f6b33c2 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -297,6 +297,7 @@ mymain(int argc, char **argv)
DO_TEST(console-compat-chardev,
QEMUD_CMD_FLAG_CHARDEV|QEMUD_CMD_FLAG_DEVICE);
DO_TEST(channel-guestfwd, QEMUD_CMD_FLAG_CHARDEV|QEMUD_CMD_FLAG_DEVICE);
+DO_TEST(channel-virtio, QEMUD_CMD_FLAG_DEVICE);
DO_TEST(watchdog, 0);
DO_TEST(watchdog-device, QEMUD_CMD_FLAG_DEVICE);
--
1.6.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH UPDATE] Add support for virtio channel
Amit pointed out that byte_limit, guest_byte_limit and cache_buffers are now gone. They are removed in these updated patches. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] Add domain support for virtio channel
Add support for virtio-serial by defining a new 'virtio' channel target type and
a virtio-serial controller. Allows the following to be specified in a domain:
controller type='virtio-serial' index='0'/
channel type='pty'
target type='virtio' name='org.linux-kvm.port.0'/
/channel
* docs/schemas/domain.rng: Add virtio-serial controller and virtio channel type.
* src/conf/domain_conf.[ch]: Domain parsing/serialization for virtio-serial
controller and virtio channel.
* tests/qemuxml2xmltest.c
tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.xml
: add domain xml parsing test
* src/libvirt_private.syms
src/qemu/qemu_conf.c: virDomainDefAddDiskControllers() renamed to
virDomainDefAddImplicitControllers()
---
docs/schemas/domain.rng| 16 -
src/conf/domain_conf.c | 71 +++
src/conf/domain_conf.h |5 +-
src/libvirt_private.syms |2 +-
src/qemu/qemu_conf.c |2 +-
.../qemuxml2argv-channel-virtio.xml| 28
tests/qemuxml2xmltest.c|1 +
7 files changed, 106 insertions(+), 19 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio.xml
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index 827ff6f..9509e80 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -530,6 +530,7 @@
valueide/value
valuescsi/value
valuesata/value
+valuevirtio-serial/value
/choice
/attribute
/optional
@@ -1120,12 +1121,25 @@
attribute name=port/
/element
/define
+ define name=virtioTarget
+element name=target
+ attribute name=type
+ valuevirtio/value
+ /attribute
+ optional
+attribute name=name/
+ /optional
+/element
+ /define
define name=channel
element name=channel
ref name=qemucdevSrcType/
interleave
ref name=qemucdevSrcDef/
-ref name=guestfwdTarget/
+choice
+ ref name=guestfwdTarget/
+ ref name=virtioTarget/
+/choice
optional
ref name=address/
/optional
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e548d1d..c514164 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -124,7 +124,8 @@ VIR_ENUM_IMPL(virDomainController,
VIR_DOMAIN_CONTROLLER_TYPE_LAST,
ide,
fdc,
scsi,
- sata)
+ sata,
+ virtio-serial)
VIR_ENUM_IMPL(virDomainFS, VIR_DOMAIN_FS_TYPE_LAST,
mount,
@@ -148,7 +149,8 @@ VIR_ENUM_IMPL(virDomainChrTarget,
VIR_DOMAIN_CHR_TARGET_TYPE_LAST,
parallel,
serial,
console,
- guestfwd)
+ guestfwd,
+ virtio)
VIR_ENUM_IMPL(virDomainChr, VIR_DOMAIN_CHR_TYPE_LAST,
null,
@@ -449,6 +451,10 @@ void virDomainChrDefFree(virDomainChrDefPtr def)
case VIR_DOMAIN_CHR_TARGET_TYPE_GUESTFWD:
VIR_FREE(def-target.addr);
break;
+
+case VIR_DOMAIN_CHR_TARGET_TYPE_VIRTIO:
+VIR_FREE(def-target.name);
+break;
}
switch (def-type) {
@@ -1460,7 +1466,7 @@ virDomainControllerDefParseXML(virConnectPtr conn,
type = virXMLPropString(node, type);
if (type) {
-if ((def-type = virDomainDiskBusTypeFromString(type)) 0) {
+if ((def-type = virDomainControllerTypeFromString(type)) 0) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_(unknown disk controller type '%s'), type);
goto error;
@@ -2081,6 +2087,10 @@ virDomainChrDefParseXML(virConnectPtr conn,
virSocketSetPort(def-target.addr, port);
break;
+case VIR_DOMAIN_CHR_TARGET_TYPE_VIRTIO:
+def-target.name = virXMLPropString(cur, name);
+break;
+
default:
virDomainReportError(conn, VIR_ERR_XML_ERROR,
_(unexpected target type type %u),
@@ -3640,12 +3650,6 @@ static virDomainDefPtr
virDomainDefParseXML(virConnectPtr conn,
}
VIR_FREE(nodes);
-/* Auto-add any further disk controllers implied by declared disk
- * elements, but not present as controller elements
- */
-if (virDomainDefAddDiskControllers(def) 0)
-goto error;
-
/* analysis of the filesystems */
if ((n = virXPathNodeSet(conn, ./devices/filesystem, ctxt, nodes)) 0)
{
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
@@ -3970,6 +3974,11 @@ static virDomainDefPtr
virDomainDefParseXML(virConnectPtr conn,
goto error;
}
+/*
Re: [libvirt] [PATCH] Allow a per-PCI passthrough device permissive attribute
On Thu, Jan 28, 2010 at 08:36:02AM -0500, Chris Lalancette wrote: On 01/27/2010 01:49 PM, Daniel P. Berrange wrote: On Wed, Jan 27, 2010 at 09:23:52AM -0500, Chris Lalancette wrote: Currently there is a global tag to let the administrator turn off system-wide ACS checking when doing PCI device passthrough. However, this is too coarse-grained of an attribute, since it doesn't allow setups where certain guests are trusted while other ones are untrusted. Allow more complicated setups by making the device checking a per-device setting. The more detailed explanation of why this is necessary delves deep into PCIe internals. Ideally we'd like to be able to probe devices and figure out whether it is safe to assign them. In practice, this isn't possible because PCIe allows devices to have hidden bridges that software can't discover. If you were to have two devices assigned to two different domains behind one of these hidden bridges, they could do P2P traffic and bypass all of the VT-d/IOMMU checks. The next thing we could try to do is to have a whitelist of devices that we know to be safe. For instance, instead of a hidden bridge, PCI devices can multiplex functions instead, which causes all traffic to head to an upstream bridge before P2P can take place. Additionally, some hidden PCI bridges may have ACS on-board. In both of these cases it's safe to passthrough the device(s), since they can't P2P without the IOMMU getting involved. However, even if we did have a whitelist, I think we still need a permissive attribute. For one thing, the whitelist will always be out of date with respect to new hardware, so we'd need to allow administrators to temporarily override the whitelist restriction until a new version of the whitelist came out. Also, we want to support the case where the administrator knows it is safe to assign possibly unsafe devices to a domain he trusts. A domain is only trusted until its guest OS gets exploited at which point this proposed change may let it escape into the host. If you don't have any IOMMU on your host, you can't use PCI device assignment with KVM at all, because it would not be safe in the event of guest exploit / mis- behavior. The same is true of device assignment in this non-ACS + hidden bridge case. While this is true, I don't think this is the sort of policy we should be enforcing in libvirt. Witness the users who still use Xen PV PCI passthrough, despite the fact that is unsafe. We still support them. If KVM had the ability to do non-IOMMU passthrough, I would think we would want to allow that usage through libvirt. Should we be safe by default? Absolutely. But should we give administrators enough rope to hang themselves? Yes, it's the Unix way. Since KVM does not provide for running without an IOMMU, I don't think we should be allowing bypass of the IOMMU in one small edge case. Particularly since the rules on when it is safe to do so are soo obscure that no sysadmin can realistically make a well informed decision. There are plenty of other constraints in PCI device assignment that libvirt is already checking and enforcing that we don't allow bypass of too. Thus I don't see why we should introduce a special permissive flag solely for the non-ACS edge case, while at the smae time not allowing the same permissiveness for the far more common non-IOMMU case. NB, I'm not suggesting we allow skipping of the checks for the non-IOMMU case either. Keeping a whitelist of devices up2date wrt new hardware launches is no more troublesome than the existing problem of updating the PCI-IDs databse or actually providing updated kernel releases with new drivers. If we use the permissive attribute, then every admin with a device that is known to be safe has the pain of setting the permissive attribute, every time, on every machine with this hardware. If we have a whitelist, then 99% of the time everything will just work because it will already be known to the whitelist. If the whitelist were an external datafile the admin could even extend it in the rare occasion when a new device were not known. This is a choice of make everyone solve over over again themselves, or solve it once for everybody. I don't really like the idea of a whitelist, but I like it more than just pushing the problem onto admins via per guest flags. For that matter I don't like the host level flag we have either and would rather we removed it. If only there's a 3rd way that were neither flags or whitelists ... The problem that I tried (and failed) to explain in the commit message is that even with a whitelist, it is not sufficient. The problem is that with multi-function PCI devices, software cannot tell whether it is possible to do P2P traffic. In the case that a manufacturer tells us no, our device doesn't allow P2P traffic, then great, we can add
[libvirt] libvirt: python bindings
Hi, I'm writing XenServer APIs for libvirt and trying to test it on virt-Manager. I need to build the libvirt python bindings for that. I tried this for libvirt. ./configure -with-xenapi -with-python make make install I suppose this is supposed to build a .libs directory with libvirtmod.so in the ~/libvirt/python/ But I don't seem to have this at all after build. It was a clean build with no errors. I need libvirtmod.so to link with virt-manager. I'm using libvirt version 0.7.4 Can anyone help me with this. Am I missing something here Thanks in Advance, -SP -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt: python bindings
On Thu, Jan 28, 2010 at 05:52:45PM +, Sharadha Prabhakar (3P) wrote: Hi, I'm writing XenServer APIs for libvirt and trying to test it on virt-Manager. I need to build the libvirt python bindings for that. I tried this for libvirt. ./configure -with-xenapi -with-python You need to use -- not just - with arguments, eg --with-python make make install I suppose this is supposed to build a .libs directory with libvirtmod.so in the ~/libvirt/python/ But I don't seem to have this at all after build. It was a clean build with no errors. I need libvirtmod.so to link with virt-manager. I'm using libvirt version 0.7.4 Can anyone help me with this. Am I missing something here Also make sure you have python-devel RPM installed (or equivalent) and have not disabled shared libraries when running configure. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
