From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64973C433DB for ; Thu, 18 Feb 2021 16:02:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A7D164E85 for ; Thu, 18 Feb 2021 16:02:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232983AbhBRQBn (ORCPT ); Thu, 18 Feb 2021 11:01:43 -0500 Received: from foss.arm.com ([217.140.110.172]:50568 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232802AbhBRM20 (ORCPT ); Thu, 18 Feb 2021 07:28:26 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42CAFED1; Thu, 18 Feb 2021 02:35:24 -0800 (PST) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B9D03F73B; Thu, 18 Feb 2021 02:35:22 -0800 (PST) Date: Thu, 18 Feb 2021 10:34:25 +0000 From: Andre Przywara To: Alexandru Elisei Cc: Will Deacon , Julien Thierry , kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Marc Zyngier Subject: Re: [PATCH kvmtool 06/21] hw/i8042: Refactor trap handler Message-ID: <20210218103425.26a27000@slackpad.fritz.box> In-Reply-To: <288df0e8-997c-7691-2dda-017876dba3f4@arm.com> References: <20201210142908.169597-1-andre.przywara@arm.com> <20201210142908.169597-7-andre.przywara@arm.com> <288df0e8-997c-7691-2dda-017876dba3f4@arm.com> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 11 Feb 2021 17:23:13 +0000 Alexandru Elisei wrote: > Hi Andre, > > On 12/10/20 2:28 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 > > --- > > hw/i8042.c | 68 +++++++++++++++++++++++++++--------------------------- > > 1 file changed, 34 insertions(+), 34 deletions(-) > > > > diff --git a/hw/i8042.c b/hw/i8042.c > > index 36ee183f..eb1f9d28 100644 > > --- a/hw/i8042.c > > +++ b/hw/i8042.c > > @@ -292,52 +292,52 @@ static void kbd_reset(void) > > }; > > } > > > > -/* > > - * Called when the OS has written to one of the keyboard's ports (0x60 or 0x64) > > - */ > > -static bool kbd_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > +static void kbd_io(struct kvm_cpu *vcpu, u64 addr, u8 *data, u32 len, > > + u8 is_write, void *ptr) > > { > > - switch (port) { > > - case I8042_COMMAND_REG: { > > - u8 value = kbd_read_status(); > > - ioport__write8(data, value); > > + u8 value; > > + > > + if (is_write) > > + value = ioport__read8(data); > > + > > + switch (addr) { > > + case I8042_COMMAND_REG: > > + if (is_write) > > + kbd_write_command(vcpu->kvm, value); > > + else > > + value = kbd_read_status(); > > break; > > - } > > - case I8042_DATA_REG: { > > - u8 value = kbd_read_data(); > > - ioport__write8(data, value); > > + case I8042_DATA_REG: > > + if (is_write) > > + kbd_write_data(value); > > + else > > + value = kbd_read_data(); > > break; > > - } > > - case I8042_PORT_B_REG: { > > - ioport__write8(data, 0x20); > > + case I8042_PORT_B_REG: > > + if (!is_write) > > + value = 0x20; > > break; > > - } > > default: > > - return false; > > + return; > > Any particular reason for removing the false return value? I don't see it > mentioned in the commit message. Otherwise this is identical to the two functions > it replaces. Because the MMIO handler prototype is void, in contrast to the PIO one. Since on returning "false" we only seem to panic kvmtool, this is of quite limited use, I'd say. > > } > > > > + if (!is_write) > > + ioport__write8(data, value); > > +} > > + > > +/* > > + * Called when the OS has written to one of the keyboard's ports (0x60 or 0x64) > > + */ > > +static bool kbd_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > +{ > > + kbd_io(vcpu, port, data, size, false, NULL); > > is_write is an u8, not a bool. Right, will fix this. > I never could wrap my head around the ioport convention of "in" (read) and "out" > (write). To be honest, changing is_write changed to an enum so it's crystal clear > what is happening would help with that a lot, but I guess that's a separate patch. "in" and "out" are the x86 assembly mnemonics, but it's indeed confusing, because the device side has a different view (CPU "in" means pushing data "out" of the device). I usually look at the code to see what it's actually meant to do. So yeah, I feel like a lot of those device emulations could use some update. but that's indeed something for another day. Cheers, Andre > > + > > return true; > > } > > > > static bool kbd_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > { > > - switch (port) { > > - case I8042_COMMAND_REG: { > > - u8 value = ioport__read8(data); > > - kbd_write_command(vcpu->kvm, value); > > - break; > > - } > > - case I8042_DATA_REG: { > > - u8 value = ioport__read8(data); > > - kbd_write_data(value); > > - break; > > - } > > - case I8042_PORT_B_REG: { > > - break; > > - } > > - default: > > - return false; > > - } > > + kbd_io(vcpu, port, data, size, true, NULL); > > > > return true; > > } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F219EC433DB for ; Thu, 18 Feb 2021 10:35:28 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 3BD5764E4B for ; Thu, 18 Feb 2021 10:35:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3BD5764E4B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A6F2A4B3C7; Thu, 18 Feb 2021 05:35:27 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4Lb2TeAATf7; Thu, 18 Feb 2021 05:35:26 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 76B874B3CC; Thu, 18 Feb 2021 05:35:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2868F4B397 for ; Thu, 18 Feb 2021 05:35:26 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD8HifhRPjUz for ; Thu, 18 Feb 2021 05:35:24 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C97424B38E for ; Thu, 18 Feb 2021 05:35:24 -0500 (EST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42CAFED1; Thu, 18 Feb 2021 02:35:24 -0800 (PST) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B9D03F73B; Thu, 18 Feb 2021 02:35:22 -0800 (PST) Date: Thu, 18 Feb 2021 10:34:25 +0000 From: Andre Przywara To: Alexandru Elisei Subject: Re: [PATCH kvmtool 06/21] hw/i8042: Refactor trap handler Message-ID: <20210218103425.26a27000@slackpad.fritz.box> In-Reply-To: <288df0e8-997c-7691-2dda-017876dba3f4@arm.com> References: <20201210142908.169597-1-andre.przywara@arm.com> <20201210142908.169597-7-andre.przywara@arm.com> <288df0e8-997c-7691-2dda-017876dba3f4@arm.com> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Cc: kvm@vger.kernel.org, Marc Zyngier , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 11 Feb 2021 17:23:13 +0000 Alexandru Elisei wrote: > Hi Andre, > > On 12/10/20 2:28 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 > > --- > > hw/i8042.c | 68 +++++++++++++++++++++++++++--------------------------- > > 1 file changed, 34 insertions(+), 34 deletions(-) > > > > diff --git a/hw/i8042.c b/hw/i8042.c > > index 36ee183f..eb1f9d28 100644 > > --- a/hw/i8042.c > > +++ b/hw/i8042.c > > @@ -292,52 +292,52 @@ static void kbd_reset(void) > > }; > > } > > > > -/* > > - * Called when the OS has written to one of the keyboard's ports (0x60 or 0x64) > > - */ > > -static bool kbd_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > +static void kbd_io(struct kvm_cpu *vcpu, u64 addr, u8 *data, u32 len, > > + u8 is_write, void *ptr) > > { > > - switch (port) { > > - case I8042_COMMAND_REG: { > > - u8 value = kbd_read_status(); > > - ioport__write8(data, value); > > + u8 value; > > + > > + if (is_write) > > + value = ioport__read8(data); > > + > > + switch (addr) { > > + case I8042_COMMAND_REG: > > + if (is_write) > > + kbd_write_command(vcpu->kvm, value); > > + else > > + value = kbd_read_status(); > > break; > > - } > > - case I8042_DATA_REG: { > > - u8 value = kbd_read_data(); > > - ioport__write8(data, value); > > + case I8042_DATA_REG: > > + if (is_write) > > + kbd_write_data(value); > > + else > > + value = kbd_read_data(); > > break; > > - } > > - case I8042_PORT_B_REG: { > > - ioport__write8(data, 0x20); > > + case I8042_PORT_B_REG: > > + if (!is_write) > > + value = 0x20; > > break; > > - } > > default: > > - return false; > > + return; > > Any particular reason for removing the false return value? I don't see it > mentioned in the commit message. Otherwise this is identical to the two functions > it replaces. Because the MMIO handler prototype is void, in contrast to the PIO one. Since on returning "false" we only seem to panic kvmtool, this is of quite limited use, I'd say. > > } > > > > + if (!is_write) > > + ioport__write8(data, value); > > +} > > + > > +/* > > + * Called when the OS has written to one of the keyboard's ports (0x60 or 0x64) > > + */ > > +static bool kbd_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > +{ > > + kbd_io(vcpu, port, data, size, false, NULL); > > is_write is an u8, not a bool. Right, will fix this. > I never could wrap my head around the ioport convention of "in" (read) and "out" > (write). To be honest, changing is_write changed to an enum so it's crystal clear > what is happening would help with that a lot, but I guess that's a separate patch. "in" and "out" are the x86 assembly mnemonics, but it's indeed confusing, because the device side has a different view (CPU "in" means pushing data "out" of the device). I usually look at the code to see what it's actually meant to do. So yeah, I feel like a lot of those device emulations could use some update. but that's indeed something for another day. Cheers, Andre > > + > > return true; > > } > > > > static bool kbd_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > { > > - switch (port) { > > - case I8042_COMMAND_REG: { > > - u8 value = ioport__read8(data); > > - kbd_write_command(vcpu->kvm, value); > > - break; > > - } > > - case I8042_DATA_REG: { > > - u8 value = ioport__read8(data); > > - kbd_write_data(value); > > - break; > > - } > > - case I8042_PORT_B_REG: { > > - break; > > - } > > - default: > > - return false; > > - } > > + kbd_io(vcpu, port, data, size, true, NULL); > > > > return true; > > } _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FE2CC433E0 for ; Thu, 18 Feb 2021 10:37:54 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E53C464E4B for ; Thu, 18 Feb 2021 10:37:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E53C464E4B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wPjxTlauf9mCl5Q8E8vUKyFK2fERHxAPfKuA+ieJ0C4=; b=NrIx+koGqiIiyAAu5BFSEc24f yBaF8pBF2jdkbW+nK5aBfR8KhRoNh612Zw0QMHjT0+E7sd4T+DclDtwzsGDUdcEtxQOpC6Y0t8trT cuSdU2lqBfwE3B88PLQt3LW6wuQGhBvWnm9/IHRM3DTkB8mnlNpLhZ1JHNbNIlnUHnngXEWEWg4fL 8JNM6ztS39SRJCxmI1sGc5vPNoKlrJaWFLuVkA/mC0xMbiTmVvgV13Q+5bg6kceYmZ/lxVhLpZq3I 6GWmg70ixFHaikKS93iQifscAco9uTomlBU0VfICtWdLGHadZiyD+DIY8cm75xG63Zoxl17qJNl0a Evuge+MMQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCgei-0003gL-4h; Thu, 18 Feb 2021 10:35:32 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCgef-0003fp-1r for linux-arm-kernel@lists.infradead.org; Thu, 18 Feb 2021 10:35:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42CAFED1; Thu, 18 Feb 2021 02:35:24 -0800 (PST) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B9D03F73B; Thu, 18 Feb 2021 02:35:22 -0800 (PST) Date: Thu, 18 Feb 2021 10:34:25 +0000 From: Andre Przywara To: Alexandru Elisei Subject: Re: [PATCH kvmtool 06/21] hw/i8042: Refactor trap handler Message-ID: <20210218103425.26a27000@slackpad.fritz.box> In-Reply-To: <288df0e8-997c-7691-2dda-017876dba3f4@arm.com> References: <20201210142908.169597-1-andre.przywara@arm.com> <20201210142908.169597-7-andre.przywara@arm.com> <288df0e8-997c-7691-2dda-017876dba3f4@arm.com> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210218_053529_249567_57C80738 X-CRM114-Status: GOOD ( 28.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, Marc Zyngier , Julien Thierry , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 11 Feb 2021 17:23:13 +0000 Alexandru Elisei wrote: > Hi Andre, > > On 12/10/20 2:28 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 > > --- > > hw/i8042.c | 68 +++++++++++++++++++++++++++--------------------------- > > 1 file changed, 34 insertions(+), 34 deletions(-) > > > > diff --git a/hw/i8042.c b/hw/i8042.c > > index 36ee183f..eb1f9d28 100644 > > --- a/hw/i8042.c > > +++ b/hw/i8042.c > > @@ -292,52 +292,52 @@ static void kbd_reset(void) > > }; > > } > > > > -/* > > - * Called when the OS has written to one of the keyboard's ports (0x60 or 0x64) > > - */ > > -static bool kbd_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > +static void kbd_io(struct kvm_cpu *vcpu, u64 addr, u8 *data, u32 len, > > + u8 is_write, void *ptr) > > { > > - switch (port) { > > - case I8042_COMMAND_REG: { > > - u8 value = kbd_read_status(); > > - ioport__write8(data, value); > > + u8 value; > > + > > + if (is_write) > > + value = ioport__read8(data); > > + > > + switch (addr) { > > + case I8042_COMMAND_REG: > > + if (is_write) > > + kbd_write_command(vcpu->kvm, value); > > + else > > + value = kbd_read_status(); > > break; > > - } > > - case I8042_DATA_REG: { > > - u8 value = kbd_read_data(); > > - ioport__write8(data, value); > > + case I8042_DATA_REG: > > + if (is_write) > > + kbd_write_data(value); > > + else > > + value = kbd_read_data(); > > break; > > - } > > - case I8042_PORT_B_REG: { > > - ioport__write8(data, 0x20); > > + case I8042_PORT_B_REG: > > + if (!is_write) > > + value = 0x20; > > break; > > - } > > default: > > - return false; > > + return; > > Any particular reason for removing the false return value? I don't see it > mentioned in the commit message. Otherwise this is identical to the two functions > it replaces. Because the MMIO handler prototype is void, in contrast to the PIO one. Since on returning "false" we only seem to panic kvmtool, this is of quite limited use, I'd say. > > } > > > > + if (!is_write) > > + ioport__write8(data, value); > > +} > > + > > +/* > > + * Called when the OS has written to one of the keyboard's ports (0x60 or 0x64) > > + */ > > +static bool kbd_in(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > +{ > > + kbd_io(vcpu, port, data, size, false, NULL); > > is_write is an u8, not a bool. Right, will fix this. > I never could wrap my head around the ioport convention of "in" (read) and "out" > (write). To be honest, changing is_write changed to an enum so it's crystal clear > what is happening would help with that a lot, but I guess that's a separate patch. "in" and "out" are the x86 assembly mnemonics, but it's indeed confusing, because the device side has a different view (CPU "in" means pushing data "out" of the device). I usually look at the code to see what it's actually meant to do. So yeah, I feel like a lot of those device emulations could use some update. but that's indeed something for another day. Cheers, Andre > > + > > return true; > > } > > > > static bool kbd_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16 port, void *data, int size) > > { > > - switch (port) { > > - case I8042_COMMAND_REG: { > > - u8 value = ioport__read8(data); > > - kbd_write_command(vcpu->kvm, value); > > - break; > > - } > > - case I8042_DATA_REG: { > > - u8 value = ioport__read8(data); > > - kbd_write_data(value); > > - break; > > - } > > - case I8042_PORT_B_REG: { > > - break; > > - } > > - default: > > - return false; > > - } > > + kbd_io(vcpu, port, data, size, true, NULL); > > > > return true; > > } _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel