kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH kvmtool 13/21] hw/serial: Refactor trap handler
Date: Wed, 24 Feb 2021 14:54:22 +0000	[thread overview]
Message-ID: <20210224145422.6bfd0ff2@slackpad.fritz.box> (raw)
In-Reply-To: <85c714de-edb8-666d-49be-90539e347e30@arm.com>

On Mon, 22 Feb 2021 17:40:36 +0000
Alexandru Elisei <alexandru.elisei@arm.com> wrote:

Hi Alex,

> On 2/18/21 2:41 PM, Andre Przywara wrote:
> > On Tue, 16 Feb 2021 14:22:05 +0000
> > Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> >  
> >> Hi Andre,
> >>
> >> Patch looks good, nitpicks below.
> >>
> >> On 12/10/20 2:29 PM, Andre Przywara wrote:  
> >>> With the planned retirement of the special ioport emulation code, we
> >>> need to provide an emulation function compatible with the MMIO prototype.
> >>>
> >>> Adjust the trap handler to use that new function, and provide shims to
> >>> implement the old ioport interface, for now.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>> ---
> >>>  hw/serial.c | 97 +++++++++++++++++++++++++++++++++++------------------
> >>>  1 file changed, 65 insertions(+), 32 deletions(-)
> >>>
> >>> diff --git a/hw/serial.c b/hw/serial.c
> >>> index b0465d99..2907089c 100644
> >>> --- a/hw/serial.c
> >>> +++ b/hw/serial.c
> >>> @@ -242,36 +242,31 @@ void serial8250__inject_sysrq(struct kvm *kvm, char sysrq)
> >>>  	sysrq_pending = sysrq;
> >>>  }
> >>>  
> >>> -static bool serial8250_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port,
> >>> -			   void *data, int size)
> >>> +static bool serial8250_out(struct serial8250_device *dev, struct kvm_cpu *vcpu,
> >>> +			   u16 offset, u8 data)
> >>>  {
> >>> -	struct serial8250_device *dev = ioport->priv;
> >>> -	u16 offset;
> >>>  	bool ret = true;
> >>> -	char *addr = data;
> >>>  
> >>>  	mutex_lock(&dev->mutex);
> >>>  
> >>> -	offset = port - dev->iobase;
> >>> -
> >>>  	switch (offset) {
> >>>  	case UART_TX:
> >>>  		if (dev->lcr & UART_LCR_DLAB) {
> >>> -			dev->dll = ioport__read8(data);
> >>> +			dev->dll = data;
> >>>  			break;
> >>>  		}
> >>>  
> >>>  		/* Loopback mode */
> >>>  		if (dev->mcr & UART_MCR_LOOP) {
> >>>  			if (dev->rxcnt < FIFO_LEN) {
> >>> -				dev->rxbuf[dev->rxcnt++] = *addr;
> >>> +				dev->rxbuf[dev->rxcnt++] = data;
> >>>  				dev->lsr |= UART_LSR_DR;
> >>>  			}
> >>>  			break;
> >>>  		}
> >>>  
> >>>  		if (dev->txcnt < FIFO_LEN) {
> >>> -			dev->txbuf[dev->txcnt++] = *addr;
> >>> +			dev->txbuf[dev->txcnt++] = data;
> >>>  			dev->lsr &= ~UART_LSR_TEMT;
> >>>  			if (dev->txcnt == FIFO_LEN / 2)
> >>>  				dev->lsr &= ~UART_LSR_THRE;
> >>> @@ -283,18 +278,18 @@ static bool serial8250_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port
> >>>  		break;
> >>>  	case UART_IER:
> >>>  		if (!(dev->lcr & UART_LCR_DLAB))
> >>> -			dev->ier = ioport__read8(data) & 0x0f;
> >>> +			dev->ier = data & 0x0f;
> >>>  		else
> >>> -			dev->dlm = ioport__read8(data);
> >>> +			dev->dlm = data;
> >>>  		break;
> >>>  	case UART_FCR:
> >>> -		dev->fcr = ioport__read8(data);
> >>> +		dev->fcr = data;
> >>>  		break;
> >>>  	case UART_LCR:
> >>> -		dev->lcr = ioport__read8(data);
> >>> +		dev->lcr = data;
> >>>  		break;
> >>>  	case UART_MCR:
> >>> -		dev->mcr = ioport__read8(data);
> >>> +		dev->mcr = data;
> >>>  		break;
> >>>  	case UART_LSR:
> >>>  		/* Factory test */
> >>> @@ -303,7 +298,7 @@ static bool serial8250_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port
> >>>  		/* Not used */
> >>>  		break;
> >>>  	case UART_SCR:
> >>> -		dev->scr = ioport__read8(data);
> >>> +		dev->scr = data;
> >>>  		break;
> >>>  	default:
> >>>  		ret = false;
> >>> @@ -336,46 +331,43 @@ static void serial8250_rx(struct serial8250_device *dev, void *data)
> >>>  	}
> >>>  }
> >>>  
> >>> -static bool serial8250_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size)
> >>> +static bool serial8250_in(struct serial8250_device *dev, struct kvm_cpu *vcpu,
> >>> +			  u16 offset, u8 *data)
> >>>  {
> >>> -	struct serial8250_device *dev = ioport->priv;
> >>> -	u16 offset;
> >>>  	bool ret = true;
> >>>  
> >>>  	mutex_lock(&dev->mutex);
> >>>  
> >>> -	offset = port - dev->iobase;
> >>> -
> >>>  	switch (offset) {
> >>>  	case UART_RX:
> >>>  		if (dev->lcr & UART_LCR_DLAB)
> >>> -			ioport__write8(data, dev->dll);
> >>> +			*data = dev->dll;
> >>>  		else
> >>>  			serial8250_rx(dev, data);
> >>>  		break;
> >>>  	case UART_IER:
> >>>  		if (dev->lcr & UART_LCR_DLAB)
> >>> -			ioport__write8(data, dev->dlm);
> >>> +			*data = dev->dlm;
> >>>  		else
> >>> -			ioport__write8(data, dev->ier);
> >>> +			*data = dev->ier;
> >>>  		break;
> >>>  	case UART_IIR:
> >>> -		ioport__write8(data, dev->iir | UART_IIR_TYPE_BITS);
> >>> +		*data = dev->iir | UART_IIR_TYPE_BITS;
> >>>  		break;
> >>>  	case UART_LCR:
> >>> -		ioport__write8(data, dev->lcr);
> >>> +		*data = dev->lcr;
> >>>  		break;
> >>>  	case UART_MCR:
> >>> -		ioport__write8(data, dev->mcr);
> >>> +		*data = dev->mcr;
> >>>  		break;
> >>>  	case UART_LSR:
> >>> -		ioport__write8(data, dev->lsr);
> >>> +		*data = dev->lsr;
> >>>  		break;
> >>>  	case UART_MSR:
> >>> -		ioport__write8(data, dev->msr);
> >>> +		*data = dev->msr;
> >>>  		break;
> >>>  	case UART_SCR:
> >>> -		ioport__write8(data, dev->scr);
> >>> +		*data = dev->scr;
> >>>  		break;
> >>>  	default:
> >>>  		ret = false;
> >>> @@ -389,6 +381,47 @@ static bool serial8250_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port,
> >>>  	return ret;
> >>>  }
> >>>  
> >>> +static void serial8250_mmio(struct kvm_cpu *vcpu, u64 addr, u8 *data, u32 len,
> >>> +			    u8 is_write, void *ptr)
> >>> +{
> >>> +	struct serial8250_device *dev = ptr;
> >>> +	u8 value = 0;
> >>> +
> >>> +	if (is_write) {
> >>> +		 value = *data;    
> >> Extra space before value.
> >>  
> >>> +
> >>> +		serial8250_out(dev, vcpu, addr - dev->iobase, value);
> >>> +	} else {
> >>> +		if (serial8250_in(dev, vcpu, addr - dev->iobase, &value))
> >>> +			*data = value;
> >>> +	}
> >>> +}
> >>> +
> >>> +static bool serial8250_ioport_out(struct ioport *ioport, struct kvm_cpu *vcpu,
> >>> +				  u16 port, void *data, int size)
> >>> +{
> >>> +	struct serial8250_device *dev = ioport->priv;
> >>> +	u8 value = ioport__read8(data);
> >>> +
> >>> +	serial8250_mmio(vcpu, port, &value, 1, true, dev);
> >>> +
> >>> +	return true;
> >>> +}
> >>> +
> >>> +static bool serial8250_ioport_in(struct ioport *ioport, struct kvm_cpu *vcpu,
> >>> +				 u16 port, void *data, int size)
> >>> +{
> >>> +	struct serial8250_device *dev = ioport->priv;
> >>> +	u8 value = 0;
> >>> +
> >>> +
> >>> +	serial8250_mmio(vcpu, port, &value, 1, false, dev);
> >>> +
> >>> +	ioport__write8(data, value);    
> >> This is correct, but confusing. You pass the address of a local variable as *data
> >> to serial8250_mmio, serial8250_mmio conditionally updates the value at data (which
> >> is &value from here), and then here we update the *data unconditionally. Why not
> >> pass data directly to serial8250_mmio and skip the local variable? Am I missing
> >> something?  
> > The idea is to keep the abstraction of ioport__write<x>. I agree this
> > is somewhat pointless for a single byte write, since the purpose of
> > those wrappers is to deal with endianness, but it seems nice to use
> > that anyway, anywhere, in case we need to add something to the wrappers
> > at some point.  
> 
> What I was thinking was something like this:
> 
> @@ -385,25 +386,19 @@ static void serial8250_mmio(struct kvm_cpu *vcpu, u64 addr,
> u8 *data, u32 len,
>                             u8 is_write, void *ptr)
>  {
>         struct serial8250_device *dev = ptr;
> -       u8 value = 0;
>  
> -       if (is_write) {
> -                value = *data;
> -
> -               serial8250_out(dev, vcpu, addr - dev->iobase, value);
> -       } else {
> -               if (serial8250_in(dev, vcpu, addr - dev->iobase, &value))
> -                       *data = value;
> -       }
> +       if (is_write)
> +               serial8250_out(dev, vcpu, addr - dev->iobase, data);
> +       else
> +               serial8250_in(dev, vcpu, addr - dev->iobase, data);
>  }
>  
>  static bool serial8250_ioport_out(struct ioport *ioport, struct kvm_cpu *vcpu,
>                                   u16 port, void *data, int size)
>  {
>         struct serial8250_device *dev = ioport->priv;
> -       u8 value = ioport__read8(data);
>  
> -       serial8250_mmio(vcpu, port, &value, 1, true, dev);
> +       serial8250_mmio(vcpu, port, data, 1, true, dev);
>  
>         return true;
>  }
> @@ -412,12 +407,8 @@ static bool serial8250_ioport_in(struct ioport *ioport,
> struct kvm_cpu *vcpu,
>                                  u16 port, void *data, int size)
>  {
>         struct serial8250_device *dev = ioport->priv;
> -       u8 value = 0;
> -
> -
> -       serial8250_mmio(vcpu, port, &value, 1, false, dev);
>  
> -       ioport__write8(data, value);
> +       serial8250_mmio(vcpu, port, data, 1, false, dev);
>  
>         return true;
>  }
> 
> And the ioport_{read,write}8 function will used inside the serial8250_{out,in}
> functions, like they were before this patch, which should also make the diff
> smaller. Or is there something that I'm missing which makes this unfeasible?

Now I remember what the problem was:
The comment before the definition of ioport__read16() says the PowerPC
needs to byteswap specifically PCI port I/O, but apparently not MMIO.
So I moved the ioport wrappers out of the actual handlers, and in *this*
patch they are just in the PIO path, so make it fit for both kind of
traps.
Now with dropping the PIO specific path in the next patch we lose this
differentiation. This is not a real problem here, since all accesses
are 8 bit wide only, which doesn't do anything, really.

I think a proper fix for this problem would be to do the byteswapping
*once*, very early (write) or late (read) in the KVM_RUN
exit handling, or in the kvm__emulate_io() function. So that the
whole device emulation always works in native endianness, and can use
pointers at will. But this would obviously be another patch.

So in preparation for this I could drop all usage of
ioport__{read,write}8 from this file, and use pointers all the way.
That wouldn't change anything (since it's byte accesses only anyway),
but would already prepare for this move.

What do you think?

Cheers,
Andre

> > ioport__write8() is a static inline in a header file, so it shouldn't
> > really hurt, the compiler is able to see through it. The generated code
> > is almost the same, at least.
> >
> > Let me know what you think!
> >
> > Cheers,
> > Andre
> >  
> >>> +
> >>> +	return true;
> >>> +}
> >>> +
> >>>  #ifdef CONFIG_HAS_LIBFDT
> >>>  
> >>>  char *fdt_stdout_path = NULL;
> >>> @@ -427,8 +460,8 @@ void serial8250_generate_fdt_node(void *fdt, struct device_header *dev_hdr,
> >>>  #endif
> >>>  
> >>>  static struct ioport_operations serial8250_ops = {
> >>> -	.io_in			= serial8250_in,
> >>> -	.io_out			= serial8250_out,
> >>> +	.io_in			= serial8250_ioport_in,
> >>> +	.io_out			= serial8250_ioport_out,
> >>>  };
> >>>  
> >>>  static int serial8250__device_init(struct kvm *kvm,    


  reply	other threads:[~2021-02-24 15:51 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 14:28 [PATCH kvmtool 00/21] Unify I/O port and MMIO trap handling Andre Przywara
2020-12-10 14:28 ` [PATCH kvmtool 01/21] ioport: Remove ioport__setup_arch() Andre Przywara
2021-02-10 17:44   ` Alexandru Elisei
2021-02-11 17:16     ` Andre Przywara
2021-02-11 17:32       ` Alexandru Elisei
2021-02-17 16:46         ` Andre Przywara
2021-02-22 10:23           ` Andre Przywara
2021-02-22 15:01             ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 02/21] hw/serial: Use device abstraction for FDT generator function Andre Przywara
2021-02-11 12:05   ` Alexandru Elisei
2021-02-11 17:45     ` Andre Przywara
2020-12-10 14:28 ` [PATCH kvmtool 03/21] ioport: Retire .generate_fdt_node functionality Andre Przywara
2021-02-11 14:05   ` Alexandru Elisei
2021-02-17 15:54     ` Andre Przywara
2021-02-17 16:06       ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 04/21] mmio: Extend handling to include ioport emulation Andre Przywara
2021-02-11 16:10   ` Alexandru Elisei
2021-02-17 17:43     ` Andre Przywara
2021-02-22 15:50       ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 05/21] hw/i8042: Clean up data types Andre Przywara
2021-02-11 16:55   ` Alexandru Elisei
2021-02-17 17:46     ` Andre Przywara
2020-12-10 14:28 ` [PATCH kvmtool 06/21] hw/i8042: Refactor trap handler Andre Przywara
2021-02-11 17:23   ` Alexandru Elisei
2021-02-18 10:34     ` Andre Przywara
2021-02-18 11:17       ` Alexandru Elisei
2021-02-18 11:48         ` Andre Przywara
2021-02-22 16:03           ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 07/21] hw/i8042: Switch to new trap handlers Andre Przywara
2021-02-12 10:41   ` Alexandru Elisei
2021-02-18 12:09     ` Andre Przywara
2021-02-22 16:19       ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 08/21] x86/ioport: Refactor " Andre Przywara
2021-02-12 11:14   ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 09/21] x86/ioport: Switch to new " Andre Przywara
2021-02-12 11:27   ` Alexandru Elisei
2021-02-18 14:05     ` Andre Przywara
2020-12-10 14:28 ` [PATCH kvmtool 10/21] hw/rtc: Refactor " Andre Przywara
2021-02-12 11:56   ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 11/21] hw/rtc: Switch to new trap handler Andre Przywara
2021-02-12 12:02   ` Alexandru Elisei
2020-12-10 14:28 ` [PATCH kvmtool 12/21] hw/vesa: Switch trap handling to use MMIO handler Andre Przywara
2021-02-12 17:50   ` Alexandru Elisei
2020-12-10 14:29 ` [PATCH kvmtool 13/21] hw/serial: Refactor trap handler Andre Przywara
2021-02-16 14:22   ` Alexandru Elisei
2021-02-18 14:41     ` Andre Przywara
2021-02-22 17:40       ` Alexandru Elisei
2021-02-24 14:54         ` Andre Przywara [this message]
2020-12-10 14:29 ` [PATCH kvmtool 14/21] hw/serial: Switch to new trap handlers Andre Przywara
2021-02-16 14:31   ` Alexandru Elisei
2020-12-10 14:29 ` [PATCH kvmtool 15/21] vfio: Refactor ioport trap handler Andre Przywara
2021-02-16 14:47   ` Alexandru Elisei
2021-02-18 15:51     ` Andre Przywara
2020-12-10 14:29 ` [PATCH kvmtool 16/21] vfio: Switch to new ioport trap handlers Andre Przywara
2021-02-16 14:52   ` Alexandru Elisei
2020-12-10 14:29 ` [PATCH kvmtool 17/21] virtio: Switch trap handling to use MMIO handler Andre Przywara
2021-02-16 17:03   ` Alexandru Elisei
2021-02-18 16:13     ` Andre Przywara
2020-12-10 14:29 ` [PATCH kvmtool 18/21] pci: " Andre Przywara
2021-02-17 15:14   ` Alexandru Elisei
2020-12-10 14:29 ` [PATCH kvmtool 19/21] Remove ioport specific routines Andre Przywara
2021-02-17 15:49   ` Alexandru Elisei
2021-02-17 16:11     ` Alexandru Elisei
2021-02-18 16:34       ` Andre Przywara
2020-12-10 14:29 ` [PATCH kvmtool 20/21] hw/serial: ARM/arm64: Use MMIO at higher addresses Andre Przywara
2021-02-17 16:48   ` Alexandru Elisei
2021-02-18 12:18     ` Alexandru Elisei
2021-02-18 16:38       ` Andre Przywara
2020-12-10 14:29 ` [PATCH kvmtool 21/21] hw/rtc: " Andre Przywara
2021-02-18 13:33   ` Alexandru Elisei
2021-02-18 16:41     ` Andre Przywara
2021-02-10 17:44 ` [PATCH kvmtool 00/21] Unify I/O port and MMIO trap handling Alexandru Elisei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210224145422.6bfd0ff2@slackpad.fritz.box \
    --to=andre.przywara@arm.com \
    --cc=alexandru.elisei@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).