Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390597 > unrolled thread

[PATCH] 8250: Hypervisors always export working 16550A UARTs.

Back to article view | Back to linux.kernel

Contents

  [PATCH] 8250: Hypervisors always export working 16550A UARTs. "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-29 00:20 +0200
    Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs. Peter Hurley <peter@hurleysoftware.com> - 2016-04-29 02:10 +0200
    Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs. "Matwey V. Kornilov" <matwey@sai.msu.ru> - 2016-04-29 09:10 +0200
      Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs. "Richard W.M. Jones" <rjones@redhat.com> - 2016-04-29 09:50 +0200
        Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs. Greg KH <gregkh@linuxfoundation.org> - 2016-04-29 17:20 +0200

#1390597 — [PATCH] 8250: Hypervisors always export working 16550A UARTs.

[This is an opinionated patch, mainly for discussion.]

I'm trying to reduce the time taken in the kernel in initcalls, with
my aim being to reduce the current ~700ms spent in initcalls before
userspace, down to something like 100ms.  All times on my Broadwell-U
laptop, under virtualization.  The purpose of this is to be able to
launch VMs around containers with minimal overhead, like Intel Clear
Containers, but using standard distro kernels and qemu.

Currently the kernel spends 25ms inspecting the UART that we passed to
it from qemu to find out whether it's an 8250/16550/16550A perhaps
with a non-working FIFO or other quirks.  Well, it isn't -- it's a
working emulated 16550A, with a FIFO and no quirks, and if it isn't,
we should fix qemu.

So the patch detects if we're running virtualized (perhaps it should
only check for qemu/KVM?) and if so, shortcuts the tests.

Rich.

[toc] | [next] | [standalone]

#1390657

On 04/28/2016 03:18 PM, Richard W.M. Jones wrote:
> [This is an opinionated patch, mainly for discussion.]
> 
> I'm trying to reduce the time taken in the kernel in initcalls, with
> my aim being to reduce the current ~700ms spent in initcalls before
> userspace, down to something like 100ms.  All times on my Broadwell-U
> laptop, under virtualization.  The purpose of this is to be able to
> launch VMs around containers with minimal overhead, like Intel Clear
> Containers, but using standard distro kernels and qemu.
> 
> Currently the kernel spends 25ms inspecting the UART that we passed to
> it from qemu to find out whether it's an 8250/16550/16550A perhaps
> with a non-working FIFO or other quirks.  Well, it isn't -- it's a
> working emulated 16550A, with a FIFO and no quirks, and if it isn't,
> we should fix qemu.

I'm sure all of this delay is sizing the fifo:

static int size_fifo(struct uart_8250_port *up)
{
	...
	for (count = 0; count < 256; count++)
		serial_out(up, UART_TX, count);
===>	mdelay(20);/* FIXME - schedule_timeout */
	for (count = 0; (serial_in(up, UART_LSR) & UART_LSR_DR) &&
	     (count < 256); count++)
		serial_in(up, UART_RX);
	...

	return count;
}


> So the patch detects if we're running virtualized (perhaps it should
> only check for qemu/KVM?) and if so, shortcuts the tests.

Yeah, sorry, that's not going to fly.

I'm assuming x86, yes?

There's are multiple ways already supported by this driver to specify
the port based on the platform:

1. Register "serial8250" platform device.
   Set UPF_FIXED_TYPE in ::flags and PORT_16550A in ::type
2. early_serial_setup()
   Same as above, but must be before console_init()
3. Don't enumerate PNP0501 ACPI devices
   These are going to be probed dynamically
4. Add ACPI/PNP custom device
   Fixing the port type isn't supported now but could be
5. Modify the SERIAL_PORT_DFNS
   Fixing the port type isn't supported now either but could be

Regards,
Peter Hurley  

[toc] | [prev] | [next] | [standalone]

#1390815

2016-04-29 1:18 GMT+03:00 Richard W.M. Jones <rjones@redhat.com>:
> [This is an opinionated patch, mainly for discussion.]
>
> I'm trying to reduce the time taken in the kernel in initcalls, with
> my aim being to reduce the current ~700ms spent in initcalls before
> userspace, down to something like 100ms.  All times on my Broadwell-U
> laptop, under virtualization.  The purpose of this is to be able to
> launch VMs around containers with minimal overhead, like Intel Clear
> Containers, but using standard distro kernels and qemu.
>
> Currently the kernel spends 25ms inspecting the UART that we passed to
> it from qemu to find out whether it's an 8250/16550/16550A perhaps
> with a non-working FIFO or other quirks.  Well, it isn't -- it's a
> working emulated 16550A, with a FIFO and no quirks, and if it isn't,
> we should fix qemu.
>
> So the patch detects if we're running virtualized (perhaps it should
> only check for qemu/KVM?) and if so, shortcuts the tests.

Does anybody know, whether it is possible to pass through real
hardware serial port to a guest? It seems to be as simple as to pass
through an interrupt and memory IO ports.

>
> Rich.
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

[toc] | [prev] | [next] | [standalone]

#1390834

On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote:
> 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones <rjones@redhat.com>:
> > [This is an opinionated patch, mainly for discussion.]
> >
> > I'm trying to reduce the time taken in the kernel in initcalls, with
> > my aim being to reduce the current ~700ms spent in initcalls before
> > userspace, down to something like 100ms.  All times on my Broadwell-U
> > laptop, under virtualization.  The purpose of this is to be able to
> > launch VMs around containers with minimal overhead, like Intel Clear
> > Containers, but using standard distro kernels and qemu.
> >
> > Currently the kernel spends 25ms inspecting the UART that we passed to
> > it from qemu to find out whether it's an 8250/16550/16550A perhaps
> > with a non-working FIFO or other quirks.  Well, it isn't -- it's a
> > working emulated 16550A, with a FIFO and no quirks, and if it isn't,
> > we should fix qemu.
> >
> > So the patch detects if we're running virtualized (perhaps it should
> > only check for qemu/KVM?) and if so, shortcuts the tests.
> 
> Does anybody know, whether it is possible to pass through real
> hardware serial port to a guest? It seems to be as simple as to pass
> through an interrupt and memory IO ports.

In theory it seems like something VFIO could do.  Passing something as
low performance as a serial port through would seem to make little
sense though.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[toc] | [prev] | [next] | [standalone]

#1391233

On Fri, Apr 29, 2016 at 08:41:14AM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2016 at 10:01:08AM +0300, Matwey V. Kornilov wrote:
> > 2016-04-29 1:18 GMT+03:00 Richard W.M. Jones <rjones@redhat.com>:
> > > [This is an opinionated patch, mainly for discussion.]
> > >
> > > I'm trying to reduce the time taken in the kernel in initcalls, with
> > > my aim being to reduce the current ~700ms spent in initcalls before
> > > userspace, down to something like 100ms.  All times on my Broadwell-U
> > > laptop, under virtualization.  The purpose of this is to be able to
> > > launch VMs around containers with minimal overhead, like Intel Clear
> > > Containers, but using standard distro kernels and qemu.
> > >
> > > Currently the kernel spends 25ms inspecting the UART that we passed to
> > > it from qemu to find out whether it's an 8250/16550/16550A perhaps
> > > with a non-working FIFO or other quirks.  Well, it isn't -- it's a
> > > working emulated 16550A, with a FIFO and no quirks, and if it isn't,
> > > we should fix qemu.
> > >
> > > So the patch detects if we're running virtualized (perhaps it should
> > > only check for qemu/KVM?) and if so, shortcuts the tests.
> > 
> > Does anybody know, whether it is possible to pass through real
> > hardware serial port to a guest? It seems to be as simple as to pass
> > through an interrupt and memory IO ports.
> 
> In theory it seems like something VFIO could do.  Passing something as
> low performance as a serial port through would seem to make little
> sense though.

Multi-port serial PCI cards are not "low performance" and might be
passed through directly to a guest.

thanks,

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web