Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp3993665ybf; Tue, 3 Mar 2020 17:27:12 -0800 (PST) X-Google-Smtp-Source: ADFU+vtA+IzjFNwGSOt5n7DYqsT2CMknWXw14nrQlUsSK7v3BPEsyVKIykeUNSU1i1ubcvCS7PrJ X-Received: by 2002:a9d:6254:: with SMTP id i20mr590887otk.130.1583285232779; Tue, 03 Mar 2020 17:27:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583285232; cv=none; d=google.com; s=arc-20160816; b=VbWWx0L+HFEMzfFMDpb4M4/Y/lIoywYuHRb0UPfXXewh4yLZI5Ga7MnBWeq0l2XMNa Q85b5LWZYbIP/zVWcUpKqObjTrr4ax/KsjRTU5uw8MU9ZHXuroSnay2w+J6TUJwU5pDo eMQPEtgi2W2pE5NWpRJtFiIYwK0AYlFSrNQ0QPLUmpHAA+hitbqT12hUGE7SwJSDwqhv 8V9L3FwiR6SyGa9oaHom9S8PNleKaZ4CjzVO0qxDk3Sj4/8Ordn5uJOrt6mjGMuY9xlI hXNf3/sRl3NQNFFPs7aW7ozKz4gBihxLj43mKK/rCQjPOP4xQwJ0VwBDo0B4we1qhdfK 1iFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=O9pD7eTKayKhsYYKw3enP3Cpnqb80umNsGJzDDGsAM4=; b=JcIYcNLD5AtYwslL34aXvoCvs97nuTkRyCMC+/JFX87T8ubwV6M0rs9rjKgpMhkfxL /qf8oKUcvoohK3V2hcFgTk5Who/ouNInUYhPAm6Rmitpx/30J4ZJgmuoA8Qh4gPIuGa5 OIy5FVg9ADPBCsISWKt16UzF1lX5+z6dSdy20hx0GmASAMemN+EAx/j4GYUom1gjiZcS ASpRWIsQvr4gMCLSKoREimKqy7OvCyjK9HzsLgVWF9cI+kx2wW4gsOBiJFRFI+LbR8SE i+fzLQ8w6E5Tn+yX77nJp4q/iIn4chC/jWD6q4hL1T2sibIcnWbKBBLLKmVWhW33LmCn OzHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hDossmiP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r3si185904otp.292.2020.03.03.17.27.00; Tue, 03 Mar 2020 17:27:12 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hDossmiP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387472AbgCDB0U (ORCPT + 99 others); Tue, 3 Mar 2020 20:26:20 -0500 Received: from mail-vs1-f67.google.com ([209.85.217.67]:42034 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727985AbgCDB0R (ORCPT ); Tue, 3 Mar 2020 20:26:17 -0500 Received: by mail-vs1-f67.google.com with SMTP id w142so103300vsw.9 for ; Tue, 03 Mar 2020 17:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O9pD7eTKayKhsYYKw3enP3Cpnqb80umNsGJzDDGsAM4=; b=hDossmiPT5ZsYw2/No/UnWGjFk7tvNCv2mxERrWzKJ2udcQ1LHSUgCZqbpDPpatSe9 CsS5IBrOxI5WqEGk50OMnXk1qi7Cx2xaGwn8Y4MCD7gDL88s5hhhs0bmJEcU8zvNhcp0 N26ZpQs0UrOayJeWh70iaWxvSBb0pAwI9eYzx4CmScF4n2uJqX0vbIzcCyLA2eQ/JPH7 f3F0f/pr3vlw+oZU9kDCRH5y3Xe9HE6a5Cce2mMuDa5Wj0KbxrLs3aLSgXR2ju2HpGJa +duer7EVx2x02EhR1KTZpXzldgOj/IJzlYFsZ/83uEtuv68D4/4xX99ZyNwvmDf+U9zb Q76Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O9pD7eTKayKhsYYKw3enP3Cpnqb80umNsGJzDDGsAM4=; b=R5yGl6dlPm2rSml0Lyu7AIdpyP4NSuIbH/ktuc6wHBjUb3gd3s8FxvDMPL5hfQG/Dp toQXxxcHpOvburrV7QEU/NMcsNX/uOKaBWrwNJ1N+Fr8r0rkYvZTKcswISfOByyFcVG4 RjypcSbE5fCXdhpbAq7pyJJbsphJW8uai73RHirkrwWRUOhjIqtFnICB2zG6fA9UPGNA JPSyfU/+gZURKMOe/9hl7pX7JOMjMQS6n97R2X3amv7qfD0R4VD1Xkwx/gYegSWgt2wX tkQdhaj8vUDIN6TaoaeJeO3etYOsZaXTtue43cSvHuj/LkLb9GtE3HeF2JghBvy7kXFd wiXA== X-Gm-Message-State: ANhLgQ2JVPHykW2QSi34+l9LiopiDFycAlt6Hm4vmgCf1Ej0mh0iY9PK OJtEQ+jA23v0oWCB/CipGS3QaIt8oI72CLUsxvt5ejgq X-Received: by 2002:a67:f1ca:: with SMTP id v10mr471335vsm.180.1583285175252; Tue, 03 Mar 2020 17:26:15 -0800 (PST) MIME-Version: 1.0 References: <20200227210454.18217-1-alistair.francis@wdc.com> <20200228095748.uu4sqkz6y477eabc@sirius.home.kraxel.org> <20200303062437.tjoje5huts6oldrv@sirius.home.kraxel.org> In-Reply-To: <20200303062437.tjoje5huts6oldrv@sirius.home.kraxel.org> From: Alistair Francis Date: Tue, 3 Mar 2020 17:18:34 -0800 Message-ID: Subject: Re: [PATCH] drm/bochs: Remove vga write To: Gerd Hoffmann Cc: Alistair Francis , Linux Kernel Mailing List , dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, Daniel Vetter , airlied@linux.ie, Khem Raj Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 2, 2020 at 10:24 PM Gerd Hoffmann wrote: > > On Mon, Mar 02, 2020 at 02:14:02PM -0800, Alistair Francis wrote: > > On Fri, Feb 28, 2020 at 1:57 AM Gerd Hoffmann wrote: > > > > > > On Thu, Feb 27, 2020 at 01:04:54PM -0800, Alistair Francis wrote: > > > > The QEMU model for the Bochs display has no VGA memory section at offset > > > > 0x400 [1]. By writing to this register Linux can create a write to > > > > unassigned memory which depending on machine and architecture can result > > > > in a store fault. > > > > > > > > I don't see any reference to this address at OSDev [2] or in the Bochs > > > > source code. > > > > > > > > Removing this write still allows graphics to work inside QEMU with > > > > the bochs-display. > > > > > > It's not that simple. The driver also handles the qemu stdvga (-device > > > VGA, -device secondary-vga) which *does* need the vga port write. > > > There is no way for the guest to figure whenever the device is > > > secondary-vga or bochs-display. > > > > > > So how about fixing things on the host side? Does qemu patch below > > > help? > > > > That patch looks like it will fix the problem, but it doesn't seem > > like the correct fix. I would rather avoid adding a large chunk of > > dummy I/O to handle the two devices. > > It's just a single handler for the parent mmio region, so we have a > defined default action instead of undefined behavior. > > Patch just posted to qemu-devel, lets see what others think ... Thanks, let's wait and see what happens. > > > > Maybe another possible approach is to enable/disable vga access per > > > arch. On x86 this doesn't cause any problems. I guess you are on > > > risc-v? > > > > I would prefer this option. I do see this on RISC-V, but I suspect the > > issue will appear on other architectures (although how they handle I/O > > failures in QEMU is a different story). > > > > Can I just do the VGA write if x86? > > I know ppc needs it too. Not sure about other architectures. I'd > suggest to do it the other way around: blacklist known-problematic > archs. Argh, that is a little uglier. Let's circle back after receiving feedback on the QEMU patch. Alistair > > cheers, > Gerd >