5:52 a.m.
From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
Currently, PIIX3/PIIX4_USB capabilities are enabled for other platforms.
Actually, it is only supported for X86.
So this patch is to clear the capabilities for non-X86 platforms.
Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
---
src/conf/domain_conf.c | 1 +
src/qemu/qemu_capabilities.c | 3 +++
src/qemu/qemu_command.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 995cf0c..d57334a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -10453,6 +10453,7 @@ virDomainDefParseXML(virCapsPtr caps,
VIR_FREE(nodes);
/* If graphics are enabled, there's an implicit PS2 mouse */
+ /* Todo: Add implicit USB mouse and keyboard for ppc64 */
if (def->ngraphics > 0) {
virDomainInputDefPtr input;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 40022c1..ef5c69a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1307,8 +1307,11 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "hda-micro", QEMU_CAPS_HDA_MICRO },
{ "ccid-card-emulated", QEMU_CAPS_CCID_EMULATED },
{ "ccid-card-passthru", QEMU_CAPS_CCID_PASSTHRU },
+#if defined (__x86_64__) || \
+ defined (__i386__)
{ "piix3-usb-uhci", QEMU_CAPS_PIIX3_USB_UHCI },
{ "piix4-usb-uhci", QEMU_CAPS_PIIX4_USB_UHCI },
+#endif
{ "usb-ehci", QEMU_CAPS_USB_EHCI },
{ "ich9-usb-ehci1", QEMU_CAPS_ICH9_USB_EHCI1 },
{ "vt82c686b-usb-uhci", QEMU_CAPS_VT82C686B_USB_UHCI },
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 1c9bfc9..0b18be0 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -5784,6 +5784,8 @@ qemuBuildCommandLine(virConnectPtr conn,
} else if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
cont->model == -1 &&
!virQEMUCapsGet(qemuCaps, QEMU_CAPS_PIIX3_USB_UHCI)) {
+ /* usblegacy is used for ppc64 temporarily */
+ /* Todo: support -device xxx on ppc64 platform */
if (usblegacy) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("Multiple legacy USB controllers are
"
--
1.7.10.1
6:13 a.m.
Hi Eric,
This is also one bug-fix, could you help review and push to 1.0.3?
Thanks. :-)
On Wed, Feb 27, 2013 at 7:52 PM, Li Zhang <zhlcindy(a)gmail.com> wrote:
From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
Currently, PIIX3/PIIX4_USB capabilities are enabled for other platforms.
Actually, it is only supported for X86.
So this patch is to clear the capabilities for non-X86 platforms.
Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
---
src/conf/domain_conf.c | 1 +
src/qemu/qemu_capabilities.c | 3 +++
src/qemu/qemu_command.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 995cf0c..d57334a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -10453,6 +10453,7 @@ virDomainDefParseXML(virCapsPtr caps,
VIR_FREE(nodes);
/* If graphics are enabled, there's an implicit PS2 mouse */
+ /* Todo: Add implicit USB mouse and keyboard for ppc64 */
if (def->ngraphics > 0) {
virDomainInputDefPtr input;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 40022c1..ef5c69a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1307,8 +1307,11 @@ struct virQEMUCapsStringFlags
virQEMUCapsObjectTypes[] = {
{ "hda-micro", QEMU_CAPS_HDA_MICRO },
{ "ccid-card-emulated", QEMU_CAPS_CCID_EMULATED },
{ "ccid-card-passthru", QEMU_CAPS_CCID_PASSTHRU },
+#if defined (__x86_64__) || \
+ defined (__i386__)
{ "piix3-usb-uhci", QEMU_CAPS_PIIX3_USB_UHCI },
{ "piix4-usb-uhci", QEMU_CAPS_PIIX4_USB_UHCI },
+#endif
{ "usb-ehci", QEMU_CAPS_USB_EHCI },
{ "ich9-usb-ehci1", QEMU_CAPS_ICH9_USB_EHCI1 },
{ "vt82c686b-usb-uhci", QEMU_CAPS_VT82C686B_USB_UHCI },
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 1c9bfc9..0b18be0 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -5784,6 +5784,8 @@ qemuBuildCommandLine(virConnectPtr conn,
} else if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
cont->model == -1 &&
!virQEMUCapsGet(qemuCaps,
QEMU_CAPS_PIIX3_USB_UHCI)) {
+ /* usblegacy is used for ppc64 temporarily */
+ /* Todo: support -device xxx on ppc64 platform */
if (usblegacy) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("Multiple legacy USB controllers
are "
--
1.7.10.1
--
Best Regards
-Li
7:36 a.m.
On Wed, Feb 27, 2013 at 19:52:22 +0800, Li Zhang wrote:
From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
Currently, PIIX3/PIIX4_USB capabilities are enabled for other platforms.
Actually, it is only supported for X86.
So this patch is to clear the capabilities for non-X86 platforms.
...
diff --git a/src/qemu/qemu_capabilities.c
b/src/qemu/qemu_capabilities.c
index 40022c1..ef5c69a 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -1307,8 +1307,11 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "hda-micro", QEMU_CAPS_HDA_MICRO },
{ "ccid-card-emulated", QEMU_CAPS_CCID_EMULATED },
{ "ccid-card-passthru", QEMU_CAPS_CCID_PASSTHRU },
+#if defined (__x86_64__) || \
+ defined (__i386__)
{ "piix3-usb-uhci", QEMU_CAPS_PIIX3_USB_UHCI },
{ "piix4-usb-uhci", QEMU_CAPS_PIIX4_USB_UHCI },
+#endif
{ "usb-ehci", QEMU_CAPS_USB_EHCI },
{ "ich9-usb-ehci1", QEMU_CAPS_ICH9_USB_EHCI1 },
{ "vt82c686b-usb-uhci", QEMU_CAPS_VT82C686B_USB_UHCI },
NACK. QEMU capabilities depend on the binary we are going to use
(emulator tag in domain XML), they don't depend on host architecture.
Jirka
8:06 p.m.
I also hope that QEMU capabilities depend on the binary by QMP.
But the flags in virQEMUCapsObjectTypes are all set in virQEMUCapsInitQMP.
virQEMUCapsInitQMP -> virQEMUCapsProbeQMPObjects ->
virQEMUCapsProcessStringFlags(qemuCaps,
ARRAY_CARDINALITY(virQEMUCapsObjectTypes),
virQEMUCapsObjectTypes,
nvalues, values);
So, it is not reasonable to set all of these flags for every platform.
This is a problem for other non-x86 platforms.
I saw that capabilities changes a lot since I used 0.10.2 before.
Could you help look into the code to see this problem?
Thanks a lot. :)
-Li
On Wed, Feb 27, 2013 at 9:36 PM, Jiri Denemark <jdenemar(a)redhat.com> wrote:
On Wed, Feb 27, 2013 at 19:52:22 +0800, Li Zhang wrote:
> From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
>
> Currently, PIIX3/PIIX4_USB capabilities are enabled for other platforms.
> Actually, it is only supported for X86.
>
> So this patch is to clear the capabilities for non-X86 platforms.
>
...
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 40022c1..ef5c69a 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -1307,8 +1307,11 @@ struct virQEMUCapsStringFlags
virQEMUCapsObjectTypes[] = {
> { "hda-micro", QEMU_CAPS_HDA_MICRO },
> { "ccid-card-emulated", QEMU_CAPS_CCID_EMULATED },
> { "ccid-card-passthru", QEMU_CAPS_CCID_PASSTHRU },
> +#if defined (__x86_64__) || \
> + defined (__i386__)
> { "piix3-usb-uhci", QEMU_CAPS_PIIX3_USB_UHCI },
> { "piix4-usb-uhci", QEMU_CAPS_PIIX4_USB_UHCI },
> +#endif
> { "usb-ehci", QEMU_CAPS_USB_EHCI },
> { "ich9-usb-ehci1", QEMU_CAPS_ICH9_USB_EHCI1 },
> { "vt82c686b-usb-uhci", QEMU_CAPS_VT82C686B_USB_UHCI },
NACK. QEMU capabilities depend on the binary we are going to use
(emulator tag in domain XML), they don't depend on host architecture.
Jirka
--
Best Regards
-Li
8:39 p.m.
On Thu, Feb 28, 2013 at 10:06 AM, Li Zhang <zhlcindy(a)gmail.com> wrote:
So, it is not reasonable to set all of these flags for every platform.
> This is a problem for other non-x86 platforms.
>
> I saw that capabilities changes a lot since I used 0.10.2 before.
>
> Could you help look into the code to see this problem?
>
> Thanks a lot. :)
> -Li
> On Wed, Feb 27, 2013 at 9:36 PM, Jiri Denemark
<jdenemar(a)redhat.com>wrote:
>
>> On Wed, Feb 27, 2013 at 19:52:22 +0800, Li Zhang wrote:
>> > From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com>
>> >
>> > Currently, PIIX3/PIIX4_USB capabilities are enabled for other platforms.
>> > Actually, it is only supported for X86.
>> >
>> > So this patch is to clear the capabilities for non-X86 platforms.
>> >
>> ...
>> > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>> > index 40022c1..ef5c69a 100644
>> > --- a/src/qemu/qemu_capabilities.c
>> > +++ b/src/qemu/qemu_capabilities.c
>> > @@ -1307,8 +1307,11 @@ struct virQEMUCapsStringFlags
>> virQEMUCapsObjectTypes[] = {
>> > { "hda-micro", QEMU_CAPS_HDA_MICRO },
>> > { "ccid-card-emulated", QEMU_CAPS_CCID_EMULATED },
>> > { "ccid-card-passthru", QEMU_CAPS_CCID_PASSTHRU },
>> > +#if defined (__x86_64__) || \
>> > + defined (__i386__)
>> > { "piix3-usb-uhci", QEMU_CAPS_PIIX3_USB_UHCI },
>> > { "piix4-usb-uhci", QEMU_CAPS_PIIX4_USB_UHCI },
>> > +#endif
>> > { "usb-ehci", QEMU_CAPS_USB_EHCI },
>> > { "ich9-usb-ehci1", QEMU_CAPS_ICH9_USB_EHCI1 },
>> > { "vt82c686b-usb-uhci", QEMU_CAPS_VT82C686B_USB_UHCI },
>>
>> NACK. QEMU capabilities depend on the binary we are going to use
>> (emulator tag in domain XML), they don't depend on host architecture.
>>
>> Jirka
>
> --
>
> Best Regards
> -Li
>
--
Best Regards
-Li
I also hope that QEMU capabilities depend on the binary by QMP.
But the flags in virQEMUCapsObjectTypes are all set in virQEMUCapsInitQMP.
virQEMUCapsInitQMP -> virQEMUCapsProbeQMPObjects ->
virQEMUCapsProcessStringFlags(qemuCaps,
ARRAY_CARDINALITY(virQEMUCapsObjectTypes),
virQEMUCapsObjectTypes,
nvalues, values);
More information from QEMU:
I tried to execute "qom-list-types" command, I get a lot of return values
including X86 and other platforms.
So this results that most flags may be set in this function.
More comments?
Thanks.
5:39 a.m.
On Thu, Feb 28, 2013 at 10:39:56 +0800, Li Zhang wrote:
On Thu, Feb 28, 2013 at 10:06 AM, Li Zhang <zhlcindy(a)gmail.com>
wrote:
> I also hope that QEMU capabilities depend on the binary by QMP.
> But the flags in virQEMUCapsObjectTypes are all set in virQEMUCapsInitQMP.
>
> virQEMUCapsInitQMP -> virQEMUCapsProbeQMPObjects ->
> virQEMUCapsProcessStringFlags(qemuCaps,
>
> ARRAY_CARDINALITY(virQEMUCapsObjectTypes),
> virQEMUCapsObjectTypes,
> nvalues, values);
Yes, but that's fine, virQEMUCapsObjectTypes is just a lookup table
between qom objects and our internal qemu capabilities flags.
virQEMUCapsProcessStringFlags will only set flags corresponding to the
qom objects reported by qemu.
More information from QEMU:
I tried to execute "qom-list-types" command, I get a lot of return values
including X86 and other platforms.
I think this is the real problem. QEMU binary emulating PPC architecture
should not advertise x86-specific objects.
Jirka
5:47 a.m.
On 2013年02月28日 19:39, Jiri Denemark wrote:
On Thu, Feb 28, 2013 at 10:39:56 +0800, Li Zhang wrote:
> On Thu, Feb 28, 2013 at 10:06 AM, Li Zhang <zhlcindy(a)gmail.com> wrote:
>
>> I also hope that QEMU capabilities depend on the binary by QMP.
>> But the flags in virQEMUCapsObjectTypes are all set in virQEMUCapsInitQMP.
>>
>> virQEMUCapsInitQMP -> virQEMUCapsProbeQMPObjects ->
>> virQEMUCapsProcessStringFlags(qemuCaps,
>>
>> ARRAY_CARDINALITY(virQEMUCapsObjectTypes),
>> virQEMUCapsObjectTypes,
>> nvalues, values);
Yes, but that's fine, virQEMUCapsObjectTypes is just a lookup table
between qom objects and our internal qemu capabilities flags.
virQEMUCapsProcessStringFlags will only set flags corresponding to the
qom objects reported by qemu.
> More information from QEMU:
>
> I tried to execute "qom-list-types" command, I get a lot of return values
> including X86 and other platforms.
I think this is the real problem. QEMU binary emulating PPC architecture
should not advertise x86-specific objects.
It seems that command "qom-list-types" just give all architectures'
list, not related with architecture.
qemu-system-x86_64 also can get all information of other architectures.
I think it is not right way to getting capabilities by "qom-list-types".
To fix this problem can be either way of the following:
1. Specify the architectures in Libvirt as my patch.
2. Specify the architectures in QEMU by modifying "qom-list-types" command.
In my opinion, it may be better to fix it in libvirt. :)
Jirka
5:55 a.m.
On Thu, Feb 28, 2013 at 19:47:47 +0800, Li Zhang wrote:
On 2013年02月28日 19:39, Jiri Denemark wrote:
>> I tried to execute "qom-list-types" command, I get a lot of return
values
>> including X86 and other platforms.
> I think this is the real problem. QEMU binary emulating PPC architecture
> should not advertise x86-specific objects.
It seems that command "qom-list-types" just give all architectures'
list, not related with architecture.
qemu-system-x86_64 also can get all information of other architectures.
I think it is not right way to getting capabilities by "qom-list-types".
Yeah, it's either bug in qemu or libvirt should use another way of
probing this stuff.
To fix this problem can be either way of the following:
1. Specify the architectures in Libvirt as my patch.
No way. This won't work if you want to start PPC domain on an x86 host
or x86 domain on a PPC host.
2. Specify the architectures in QEMU by modifying
"qom-list-types"
command.
Perhaps. We definitely need to find the right way of probing the data we
care about. And it's likely both libvirt and qemu will need to be
modified.
Jirka
6 a.m.
On 2013年02月28日 19:55, Jiri Denemark wrote:
On Thu, Feb 28, 2013 at 19:47:47 +0800, Li Zhang wrote:
> On 2013年02月28日 19:39, Jiri Denemark wrote:
>>> I tried to execute "qom-list-types" command, I get a lot of return
values
>>> including X86 and other platforms.
>> I think this is the real problem. QEMU binary emulating PPC architecture
>> should not advertise x86-specific objects.
> It seems that command "qom-list-types" just give all architectures'
> list, not related with architecture.
> qemu-system-x86_64 also can get all information of other architectures.
>
> I think it is not right way to getting capabilities by "qom-list-types".
Yeah, it's either bug in qemu or libvirt should use another way of
probing this stuff.
> To fix this problem can be either way of the following:
> 1. Specify the architectures in Libvirt as my patch.
No way. This won't work if you want to start PPC domain on an x86 host
or x86 domain on a PPC host.
> 2. Specify the architectures in QEMU by modifying "qom-list-types"
> command.
Perhaps. We definitely need to find the right way of probing the data we
care about. And it's likely both libvirt and qemu will need to be
modified.
Got it, thanks.
I will look into it in QEMU. :)
Jirka
5:58 a.m.
On 2013年02月28日 19:47, Li Zhang wrote:
On 2013年02月28日 19:39, Jiri Denemark wrote:
> On Thu, Feb 28, 2013 at 10:39:56 +0800, Li Zhang wrote:
>> On Thu, Feb 28, 2013 at 10:06 AM, Li Zhang <zhlcindy(a)gmail.com> wrote:
>>
>
It seems that command "qom-list-types" just give all architectures'
list, not related with architecture.
qemu-system-x86_64 also can get all information of other architectures.
Sorry, qemu-syste-x86_64 didn't get list of other platforms.
I just saw wrong information.
I think it is not right way to getting capabilities by "qom-list-types".
To fix this problem can be either way of the following:
1. Specify the architectures in Libvirt as my patch.
2. Specify the architectures in QEMU by modifying "qom-list-types"
command.
In my opinion, it may be better to fix it in libvirt. :)
So I will fix this in QEMU. Please ignore this patch.
Thanks, Jiri.
> Jirka
4285
days inactive
4286
days old
9 comments
2 participants
participants (2)
-
Jiri Denemark -
Li Zhang