Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp485965imm; Fri, 28 Sep 2018 01:42:16 -0700 (PDT) X-Google-Smtp-Source: ACcGV606h6TWpJCqxOFmwcAcVzpo7TlYoPAen+5vntqGRr7h2L5/nkY8webp2bT+aKHPZ+SoSH+Y X-Received: by 2002:a62:438f:: with SMTP id l15-v6mr15833854pfi.196.1538124136662; Fri, 28 Sep 2018 01:42:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538124136; cv=none; d=google.com; s=arc-20160816; b=igkb8ueI02suiw4WNA2ZJGEYc/j5A8bjiPBVlF3exfMMO7Sx8kYsWVvzL/MHXiWp1H 0MkQ9d2S3c7ZcZgeRK3aTjBA++BreBz397FSKriu0jZx5o+zyFnOOzArAgx0zQDBn1uq 3b7d7tcBCKsCXx+p0FjzJ/hsRe4oW5A39qLQIOGcHLPbDYBF+k8SXMxPh+EEfoJpvGM5 G7hXbyZOgPl0J0FOEuRGBRi6dVsImbYssJ0HteYGUW4DtHvdqxgIfinM1MVPIQUc3tLD j1VMQImUfL01QOPlp+6lhcZ7IBx0pRbFi+MUXyhdyO+3CVsEQlHp6uN90bC3ArpdSa2n EhSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:date:message-id:from :references:cc:to:subject; bh=hTi86ycULPAwLMVN1+ifkXHO36Ss//Q5AJyRMtIbZFE=; b=AcytGLhQ8AjLP5pji9NIuvJs04udAuvpkIF10mUA0IrmZSfxJWEnafkK4AW5hCtr9z DJyGwhMp96NnbsX+BAXkZ+F/UGwaZOCaK0kh4pjjanxvglH8Mytj4f/OhiUqJjfBgWG8 Wi/uSLmVV2eWvf+Vmr9A7y0aXRQyJzKNnnx+7sWYBEnOz1Ww+sQI/UzyCiiNgHdwAobq s45E6wY7zN88hy61KhT61YnhZWSCb83AGnqFtiIS9SGzylo1lo49Z6lph/U1EQDP1V03 qCL0fL0LFyBhN4AP+1sUprmb8JzV1IVXH+tetSvZJxL3JfV+MS3DtxW8HkE9BRixdHff foxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=pxatj6AP; 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=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b41-v6si4135426pla.306.2018.09.28.01.42.00; Fri, 28 Sep 2018 01:42:16 -0700 (PDT) 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=@nvidia.com header.s=n1 header.b=pxatj6AP; 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=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729246AbeI1PDQ (ORCPT + 99 others); Fri, 28 Sep 2018 11:03:16 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:17526 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728901AbeI1PDQ (ORCPT ); Fri, 28 Sep 2018 11:03:16 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Fri, 28 Sep 2018 01:39:51 -0700 Received: from HQMAIL101.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Fri, 28 Sep 2018 01:40:35 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Fri, 28 Sep 2018 01:40:35 -0700 Received: from [10.24.70.87] (10.124.1.5) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Sep 2018 08:40:31 +0000 Subject: Re: [PATCH v3 2/2] vfio: add edid support to mbochs sample driver To: Gerd Hoffmann CC: , Alex Williamson , , open list References: <20180921083013.15028-1-kraxel@redhat.com> <20180921083013.15028-3-kraxel@redhat.com> <4b9847dd-c37d-1d5d-3343-7030e62894fb@nvidia.com> <20180928054056.vjqwxvaj7sjmsozh@sirius.home.kraxel.org> X-Nvconfidentiality: public From: Kirti Wankhede Message-ID: <646427f9-7bed-43aa-6aba-9b5e82eecb68@nvidia.com> Date: Fri, 28 Sep 2018 14:10:26 +0530 MIME-Version: 1.0 In-Reply-To: <20180928054056.vjqwxvaj7sjmsozh@sirius.home.kraxel.org> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL101.nvidia.com (172.20.187.10) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1538123991; bh=hTi86ycULPAwLMVN1+ifkXHO36Ss//Q5AJyRMtIbZFE=; h=X-PGP-Universal:Subject:To:CC:References:X-Nvconfidentiality:From: Message-ID:Date:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=pxatj6APEkz5+7mt8HesRN+EmYjfp27aEnmkOXKt8T5PISGVPECaxsQgPoBk3+5L/ kdJBXU0tfkbhzkdOrJ8sS/4AnouvfdYP7X/JlzXNbuy/7asJG0pfPZDUGBcM+ZqZP2 c5Hhe/R4VoAXQzyXMpX/KPt+T8RZ+0eizA1Rdsqd71zhyUSMXSJM4Y2AJ3X6Ol9wl6 8KaI+Fq3fmHKJLkxo2kznLIcXH4rRozwIA3lLH9WcGKU6LDI4CUV1aG4dIvfQz7gOe //FJjCU6/mTYpbLdV444/PufT1IKg2rgpdrikMK4flewq4wYpMh3sVpxvTGx9WLtfH YdmQf+/r20X8g== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/28/2018 11:10 AM, Gerd Hoffmann wrote: >>> + case MBOCHS_EDID_REGION_INDEX: >>> + ext->base.argsz = sizeof(*ext); >>> + ext->base.offset = MBOCHS_EDID_OFFSET; >>> + ext->base.size = MBOCHS_EDID_SIZE; >>> + ext->base.flags = (VFIO_REGION_INFO_FLAG_READ | >>> + VFIO_REGION_INFO_FLAG_WRITE | >>> + VFIO_REGION_INFO_FLAG_CAPS); >> >> Any reason to not to use _MMAP flag? > > There is no page backing this. Also it is not performance-critical, > edid updates should be rare, so the extra code for mmap support doesn't > look like it is worth it. > > Also for the virtual registers (especially link_state) it is probably > useful to have the write callback of the mdev driver called to get > notified about the change. > >> How would QEMU side code read this region? will it be always trapped? > > qemu uses read & write syscalls (well, pread & pwrite actually). > >> If vendor driver sets _MMAP flag, will QEMU side handle that case as well? > > The current test branch doesn't, it expects read+write to work. > https://git.kraxel.org/cgit/qemu/log/?h=sirius/edid-vfio > Ok. Can you add a comment in vfio.h that this region is non-mmappable? >> I think since its blob, edid could be read by QEMU using one memcpy >> rather than adding multiple memcpy of 4 or 8 bytes. > > From qemu it's a single pwrite syscall actually. mbochs_write() splits > it into 4 byte writes and calls mbochs_access() for each of them. One > could probably add a special case for the EDID blob to mbochs_write(). > But again: doesn't seem worth the effort given that edid updates should > be a rare event. > Ok. Thanks, Kirti > cheers, > Gerd >