Bug 998813 - [RFE] add support for pci-serial
Summary: [RFE] add support for pci-serial
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-20 06:47 UTC by Gerd Hoffmann
Modified: 2016-06-28 01:55 UTC (History)
8 users (show)

Fixed In Version: libvirt-1.2.16-1.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 05:43:37 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description Gerd Hoffmann 2013-08-20 06:47:12 UTC
Description of problem:
libvirt should allow to add pci-serial devices to guests.
Note that pci-serial devices are hotpluggable.

Comment 3 Michal Privoznik 2015-05-06 16:38:05 UTC
Patches proposed upstream:

https://www.redhat.com/archives/libvir-list/2015-May/msg00171.html

Comment 5 Michal Privoznik 2015-05-21 16:15:15 UTC
Moving to POST:

commit 04695f48b2440292d63210c012727584c65fe75f
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Mon May 11 17:05:21 2015 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Thu May 21 17:49:02 2015 +0200

    qemuDomainDetachChrDevice: Fix chardev hot-unplug
    
    Not every chardev is plugged onto virtio-serial bus. However, the
    code introduced in 89e991a2aa36b04 assumes that. Incorrectly.
    With previous patches we have three options where a chardev can
    be plugged: virtio-serial, USB and PCI. This commit fixes the
    detach part. However, since we are not auto allocating USB
    addresses yet, I'm just marking the place where appropriate code
    should go.
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

commit 9807c47147a92a423f632e799137a31acd3ac41e
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Mon May 11 15:20:54 2015 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Thu May 21 17:49:02 2015 +0200

    qemuDomainAttachChrDevice: Fix chardev hotplug
    
    Not every chardev is plugged onto virtio-serial bus. However, the
    code introduced in 89e991a2aa36b04 assumes that. Incorrectly.
    With previous patches we have three options where a chardev can
    be plugged: virtio-serial, USB and PCI. This commit fixes the
    attach part.  However, since we are not auto allocating USB
    addresses yet, I'm just marking the place where appropriate code
    should go.
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

commit 8e33cb41f39edfe8c0955af33c0bf96cee6c3bcc
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Wed May 6 17:50:03 2015 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Thu May 21 17:49:02 2015 +0200

    qemu: Implement pci-serial
    
    https://bugzilla.redhat.com/show_bug.cgi?id=998813
    
    Implementation is pretty straight-forward. Of course, not all qemus
    out there supports the device, so new capability is introduced and
    checked prior each use of the device.
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>

commit 335b834d956f029323a1eb342fd0b1e08f73fcb0
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Wed May 6 17:42:41 2015 +0200
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Thu May 21 17:49:02 2015 +0200

    Introduce pci-serial
    
    https://bugzilla.redhat.com/show_bug.cgi?id=998813
    
    Like usb-serial, the pci-serial device allows a serial device to be
    attached to PCI bus. An example XML looks like this:
    
      <serial type='dev'>
        <source path='/dev/ttyS2'/>
        <target type='pci-serial' port='0'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
      </serial>
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>


v1.2.15-131-g04695f4

Comment 7 Hu Jianwei 2015-06-29 08:56:09 UTC
Do some sanity testing for this bug.

Version:
[root@localhost ~]# rpm -q libvirt qemu-kvm-rhev
libvirt-1.2.16-1.el7.x86_64
qemu-kvm-rhev-2.3.0-1.el7.x86_64

<1> Validate XML with pci-serial type char
[root@localhost ~]# vim /usr/share/libvirt/schemas/domaincommon.rng
...
 <define name='qemucdevSerialTgtType'>
    <attribute name='type'>
      <choice>
        <value>isa-serial</value>
        <value>usb-serial</value>
        <value>pci-serial</value>
      </choice>
    </attribute>
  </define>
...


[root@localhost ~]# cat r71.xml | grep "</serial" -b5
1966-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
2048-    </interface>
2065-    <serial type='pty'>
2089-      <target type='pci-serial' port='0'/>
2132-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
2214:    </serial>
2228-    <console type='pty'>
2253-      <target type='serial' port='0'/>
2292-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
2374-    </console>
2389-    <input type='mouse' bus='ps2'/>
[root@localhost ~]# virt-xml-validate r71.xml 
r71.xml validates

<2> Start domain with such device
[root@localhost ~]# virsh dumpxml r71 | grep "</serial" -b5
1966-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
2048-    </interface>
2065-    <serial type='pty'>
2089-      <target type='pci-serial' port='0'/>
2132-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
2214:    </serial>
2228-    <console type='pty'>
2253-      <target type='serial' port='0'/>
2292-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
2374-    </console>
2389-    <input type='mouse' bus='ps2'/>
[root@localhost ~]# 
[root@localhost ~]# 
[root@localhost ~]# virsh start r71
Domain r71 started

[root@localhost ~]# virsh dumpxml r71 | grep "</serial" -b8
2210-      <alias name='net0'/>
2237-      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
2319-    </interface>
2336-    <serial type='pty'>
2360-      <source path='/dev/pts/1'/>
2394-      <target type='pci-serial' port='0'/>
2437-      <alias name='serial0'/>
2467-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
2549:    </serial>
2563-    <console type='pty' tty='/dev/pts/1'>
2605-      <source path='/dev/pts/1'/>
2639-      <target type='serial' port='0'/>
2678-      <alias name='serial0'/>
2708-      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
2790-    </console>
2805-    <input type='mouse' bus='ps2'/>
2841-    <input type='keyboard' bus='ps2'/>

<3> Docs check
[root@localhost ~]# cat /usr/share/doc/libvirt-docs-1.2.16/html/formatdomain.html  | grep "pci-serial" -b5
248960-      <code>target</code> can have a <code>port</code> attribute, which
249032-      specifies the port number. Ports are numbered starting from 0. There are
249111-      usually 0, 1 or 2 serial ports. There is also an optional
249175-      <code>type</code> attribute <span class="since">since 1.0.2</span>
249248-      which has three choices for its value, one is <code>isa-serial</code>,
249325:      then <code>usb-serial</code> and last one is <code>pci-serial</code>.
249401-      If <code>type</code> is missing, <code>isa-serial</code> will be used by
249480-      default. For <code>usb-serial</code> an optional sub-element
249547-      <code>&lt;address/&gt;</code> with <code>type='usb'</code> can tie the
249624-      device to a particular controller, <a href="#elementsAddress" shape="rect">documented above</a>.
249727:      Similarly, <code>pci-serial</code> can be used to attach the device to
249804-      the pci bus (<span class="since">since 1.2.16</span>). Again, it has
249879-      optional sub-element <code>&lt;address/&gt;</code> with
249941-      <code>type='pci'</code> to select desired location on the PCI bus.
250014-    </p>
250023-        <h6>

Comment 8 Shanzhi Yu 2015-09-01 02:27:09 UTC
Verify this bug with libvirt-1.2.17-6.el7.x86_64.
Step will be offered in later comment.

Comment 9 Shanzhi Yu 2015-09-21 09:15:33 UTC
1. define a guest with serial device to be attached to PCI bus(without PCI address)

# cat r7.xml|grep "serial type='pty'" -A 5
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <serial type='pty'>
      <target type='pci-serial' port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>

# virsh define r7.xml 
Domain r7 defined from r7.xml

# virsh dumpxml r7|grep "serial type='pty" -A 6
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <serial type='pty'>
      <target type='pci-serial' port='0'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
PCI address with auto assign when define a guest. 

2. Start guest, check live xml and qemu cmd
# virsh start r7 
Domain r7 started

# virsh dumpxml r7|grep "serial type='pty" -A 10
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target type='pci-serial' port='0'/>
      <alias name='serial1'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/>
    </serial>
# ps aux|grep pci-serial

....
-device pci-serial,chardev=charserial1,id=serial1,bus=pci.2,addr=0x2
....

3. Do hotplug/hotunplug

3.1 hotplug 

# cat pci-serial.xml 
<serial type='pty'>
<source path='/dev/pts/4'/>
<target type='pci-serial' port='0'/>
</serial>
# virsh attach-device r7 pci-serial.xml 
Device attached successfully
# virsh dumpxml r7|grep "serial type='pty" -A 10
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target type='pci-serial' port='0'/>
      <alias name='serial1'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/4'/>
      <target type='pci-serial' port='0'/>
      <alias name='serial2'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/>
    </serial>

3.2 hotunplug

# virsh detach-device r7 pci-serial.xml 
Device detached successfully

# virsh dumpxml r7|grep "serial type='pty" -A 10
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target type='pci-serial' port='0'/>
      <alias name='serial1'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/>
    </serial>

Comment 11 errata-xmlrpc 2015-11-19 05:43:37 UTC
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-2015-2202.html

Comment 12 Jingjing Shao 2016-06-16 11:00:49 UTC
Hi Michal,

I have another question about this issue: the source path changed when attach the device to the guest.
Can you help to confirm it is a bug or not ? 
Thank you in advanced.

[root@dhcp-66-71-64 jishao]# rpm -q libvirt
libvirt-1.3.4-1.el7.x86_64


1. [root@dhcp-66-71-64 jishao]# virsh list
 Id    Name                           State
----------------------------------------------------
 32    r7.1                           running

2. [root@dhcp-66-71-64 jishao]# virsh dumpxml r7.1 |grep "serial type='pty" -A 10
    <serial type='pty'>
      <source path='/dev/pts/2'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target type='pci-serial' port='0'/>
      <alias name='serial1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </serial>

3.[root@dhcp-66-71-64 jishao]# cat pci-serial.xml 
<serial type='pty'>
<source path='/dev/pts/4'/>  <=========the source is '/dev/pts/4'
<target type='pci-serial' port='0'/>
</serial>

4.[root@dhcp-66-71-64 jishao]# virsh attach-device r7.1 pci-serial.xml 
Device attached successfully

5.[root@dhcp-66-71-64 jishao]# virsh dumpxml r7.1 |grep "serial type='pty" -A 10
    <serial type='pty'>
      <source path='/dev/pts/2'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/3'/>
      <target type='pci-serial' port='0'/>
      <alias name='serial1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </serial>
    <serial type='pty'>
      <source path='/dev/pts/5'/>  <========the source is '/dev/pts/5'
      <target type='pci-serial' port='0'/>
      <alias name='serial2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </serial>

Comment 13 Michal Privoznik 2016-06-27 08:48:37 UTC
(In reply to Jingjing Shao from comment #12)
> Hi Michal,
> 
> I have another question about this issue: the source path changed when
> attach the device to the guest.
> Can you help to confirm it is a bug or not ? 
> Thank you in advanced.
> 

This behaviour is expected. It's qemu who opens the PTY for us and we just query what PTY has been opened. Regardless of qemu, there's no way how to force opening a specific PTY. The kernel decides which PTY is opened and just lets application know.

Comment 14 Jingjing Shao 2016-06-28 01:55:34 UTC
(In reply to Michal Privoznik from comment #13)
> (In reply to Jingjing Shao from comment #12)
> > Hi Michal,
> > 
> > I have another question about this issue: the source path changed when
> > attach the device to the guest.
> > Can you help to confirm it is a bug or not ? 
> > Thank you in advanced.
> > 
> 
> This behaviour is expected. It's qemu who opens the PTY for us and we just
> query what PTY has been opened. Regardless of qemu, there's no way how to
> force opening a specific PTY. The kernel decides which PTY is opened and
> just lets application know.

Thank you, Michal, I get it.


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