Bug 1291979 - [ppc64le] Virtio-input support - qemu-kvm-rhev
[ppc64le] Virtio-input support - qemu-kvm-rhev
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.2
ppc64le Linux
medium Severity medium
: rc
: ---
Assigned To: Laurent Vivier
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: RHV4.1PPC 1288337
  Show dependency treegraph
 
Reported: 2015-12-16 01:22 EST by Qunfang Zhang
Modified: 2016-11-07 16:46 EST (History)
11 users (show)

See Also:
Fixed In Version: qemu-kvm-rhev-2.5.0-1.el7
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-07 16:46:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Qunfang Zhang 2015-12-16 01:22:14 EST
Description of problem:

Create this bug to track the virtio-input related testing, currently the following devices shows up in the qemu-kvm device lists:

name "virtio-input-host-device", bus virtio-bus
name "virtio-input-host-pci", bus PCI
name "virtio-keyboard-device", bus virtio-bus
name "virtio-keyboard-pci", bus PCI
name "virtio-mouse-device", bus virtio-bus
name "virtio-mouse-pci", bus PCI
name "virtio-tablet-device", bus virtio-bus
name "virtio-tablet-pci", bus PCI

Please developer help adjust or fix something if they are not accurate.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Laurent Vivier 2016-02-23 09:06:22 EST
I've checked they work with our qemu version:

name "virtio-keyboard-device", bus virtio-bus
name "virtio-keyboard-pci", bus PCI
name "virtio-mouse-device", bus virtio-bus
name "virtio-mouse-pci", bus PCI

They work fine.

I have tested them on text console and using gpm to test the mouse.

I've also checked them with Fedora 23 graphical installer and they work fine too, + the tablet device:

name "virtio-tablet-device", bus virtio-bus
name "virtio-tablet-pci", bus PCI

I'm not able to confirm "input-host" works as I have no physical access to a host.
Comment 5 mazhang 2016-06-23 03:44:16 EDT
Just got Gerd's reply , we can skip the virtio-input-host-pci test on ppc.

On Do, 2016-06-23 at 13:41 +0800, mazhang wrote:
> Hi Gerd,
>
> I met a problem when I test Bug 1291979 - [ppc64le] Virtio-input
> support - qemu-kvm-rhev.
> We can passthrough host keyboard/mouse to guest by
> virtio-input-host-pci.
> For guest pov, use host mouse to move pointer, and host keyboard for
> input.
> But we can't physical access a ppc host, any advise for test this
> device ?

Just skip the test on ppc then.
Comment 6 mazhang 2016-06-23 03:47:24 EDT
Hi Laurent,

Please help look at c#4 and c#5, does it sufficient for verify this bug?

Thanks,
Mazhang.
Comment 7 Laurent Vivier 2016-06-23 04:29:27 EDT
As endianness can differ between host and guest, we can have here bugs we don't have on x86_64.

But how this was tested for qemu-kvm-rhev-2.3.0?
Comment 8 mazhang 2016-06-23 05:09:04 EDT
(In reply to Laurent Vivier from comment #7)
> As endianness can differ between host and guest, we can have here bugs we
> don't have on x86_64.
> 
> But how this was tested for qemu-kvm-rhev-2.3.0?

Guess you mean Bug 1248933, actually we test on qemu-kvm-rhev-2.6.0-8.el7.ppc64le, see detail on 1248933#c10.
Comment 9 Laurent Vivier 2016-06-23 05:36:45 EDT
(In reply to mazhang from comment #8)
> (In reply to Laurent Vivier from comment #7)
> > As endianness can differ between host and guest, we can have here bugs we
> > don't have on x86_64.
> > 
> > But how this was tested for qemu-kvm-rhev-2.3.0?
> 
> Guess you mean Bug 1248933, actually we test on
> qemu-kvm-rhev-2.6.0-8.el7.ppc64le, see detail on 1248933#c10.

No, I mean: how virtio-input-host was tested for qemu-kvm-rhev-2.3.0?

But the code involved in virtio-input-host is only ~200 lines, so as Gerd has proposed, I think it is acceptable to only test this on x86_64 (as communication with host is done using generic ioctls through the event interface).

And I think user will have the same problematic we have: no physical access to the server.

So, just skip the test on ppc64le.
Comment 10 mazhang 2016-06-23 05:55:32 EDT
(In reply to Laurent Vivier from comment #9)
> (In reply to mazhang from comment #8)
> > (In reply to Laurent Vivier from comment #7)
> > > As endianness can differ between host and guest, we can have here bugs we
> > > don't have on x86_64.

I'll test BE guest and update result.

> > > 
> > > But how this was tested for qemu-kvm-rhev-2.3.0?
> > 
> > Guess you mean Bug 1248933, actually we test on
> > qemu-kvm-rhev-2.6.0-8.el7.ppc64le, see detail on 1248933#c10.
> 
> No, I mean: how virtio-input-host was tested for qemu-kvm-rhev-2.3.0?
> 

virtio-input not be tested for qemu-kvm-rhev-2.3.0

> But the code involved in virtio-input-host is only ~200 lines, so as Gerd
> has proposed, I think it is acceptable to only test this on x86_64 (as
> communication with host is done using generic ioctls through the event
> interface).
> 
> And I think user will have the same problematic we have: no physical access
> to the server.
> 
> So, just skip the test on ppc64le.
Comment 11 mazhang 2016-06-29 04:36:32 EDT
Test this bug with RHEL7.3 GE guest.

Host:
3.10.0-456.el7.ppc64le
qemu-kvm-rhev-2.6.0-10.el7.ppc64le

Guest:
3.10.0-456.el7.ppc64

No new bugs found.

Base on comment#4 comment#5 and above comment set this bug as verified, if any problem please let me know, thanks.
Comment 13 errata-xmlrpc 2016-11-07 16:46:15 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html

Note You need to log in before you can comment on or make changes to this bug.