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 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3CB4FC433F5 for ; Thu, 31 Mar 2022 14:19:43 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.297000.505759 (Exim 4.92) (envelope-from ) id 1nZve4-0004wq-1B; Thu, 31 Mar 2022 14:19:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 297000.505759; Thu, 31 Mar 2022 14:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1nZve3-0004wj-UT; Thu, 31 Mar 2022 14:19:27 +0000 Received: by outflank-mailman (input) for mailman id 297000; Thu, 31 Mar 2022 14:19:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1nZve2-0004wd-IO for xen-devel@lists.xenproject.org; Thu, 31 Mar 2022 14:19:26 +0000 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [2a00:1450:4864:20::133]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 915ef5af-b0fd-11ec-a405-831a346695d4; Thu, 31 Mar 2022 16:19:25 +0200 (CEST) Received: by mail-lf1-x133.google.com with SMTP id m3so41771483lfj.11 for ; Thu, 31 Mar 2022 07:19:25 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 915ef5af-b0fd-11ec-a405-831a346695d4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HMSPM73FMTrJK/ya9lqUErQGcfG51bxLwARlbNHr9fY=; b=I6rBTWQ73cN/0cKPwHkFnGK3Eo0RUPTwjSRxsTWb0GHMDceN/jUdhRBrE77p6mLERO r7nObjDYU5V1P4Ij7i1AieIe9lDbLjk8EIgfpgl0kpbpiVMcVKR1QmV1v4rGnLTO8AV/ aqEtvjLcfHG7xVWfqXBKFXHXz1uS3rAG0nFgReJCgkCpAARvZEgpZbyJNA2aXAz1XunC 2ZvfEVfoFAV0UkB57jj4gfiCJg4ykAOSdbJjl8XNv/4Vg/HssCMJeBf7ZhCyHkapeblc HTOkMIP9K/9CgIGxPSrq8VsWMJ76YxyV+b5Iuj/ATASeIDiQVB7kjixXQzSOcpycdOji FtGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HMSPM73FMTrJK/ya9lqUErQGcfG51bxLwARlbNHr9fY=; b=EFi4sY67MgjlJRYArYnQJ7gRWz+Secbe7NKtIVHc490eVlfYRWYPbWBeNOxwVM3mW8 WmdndEHzIILDrXv2U7kKYYzDM6LSMuBpcl0M14DHG8uk52I8EKLBmMRanq5phbLWny// xPAMQmmAADMrxqeR0lwtd9h+RDFtQ1Xw+t6yjPNc6gJjaN+4m8LMkD6BLdHBRbQQkpAi e/JUcfYzkqZdMCxGoVcnUJf77LCeElGI7kpcht7zviHXViqQ/19ho4/LzH+OSKDyx2pH JaY9UqYjqrH8FIFZsm1DlhYnnLHoCVs8mF6DO0ReCuLuwePHWLnu/3d0gR3bRJ/S/ozL /G7g== X-Gm-Message-State: AOAM532vRVoz4BWHlf3zi5FvE42prSh3hTL1piMvJnlDDezZkeguO+eE jjQp14DjVdGT8hXrB6WcyQHHNTxU/cWc4/ILefI= X-Google-Smtp-Source: ABdhPJzwIgYRIgaXFtongyXSQnAUh/nAeowNgQPw+EeiwSdTjKjHSTKz/UmXswsrs8aFy2xQ86iKJzWVnYStYn41Wx0= X-Received: by 2002:a19:d61a:0:b0:43f:1a03:21ee with SMTP id n26-20020a19d61a000000b0043f1a0321eemr11110801lfg.152.1648736364380; Thu, 31 Mar 2022 07:19:24 -0700 (PDT) MIME-Version: 1.0 References: <408e5e07-453c-f377-a5b0-c421d002aec5@srcf.net> <46a8585e-2a2a-4d12-f221-e57bd157dec6@netscape.net> In-Reply-To: From: Jason Andryuk Date: Thu, 31 Mar 2022 10:19:12 -0400 Message-ID: Subject: Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion To: Chuck Zmudzinski Cc: Andrew Cooper , Anthony PERARD , xen-devel , Wei Liu , Juergen Gross , Jan Beulich Content-Type: text/plain; charset="UTF-8" On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski wrote: > > On 3/31/2022 8:29 AM, Jason Andryuk wrote: > > On Wed, Mar 30, 2022 at 11:54 PM Chuck Zmudzinski wrote: > >> On 3/30/22 1:27 PM, Andrew Cooper wrote: > >>> > >>> This has been discussed before, but noone's done anything about it. > >>> It's a massive layering violation for QEMU to issue > >>> xc_domain_iomem_permission()/etc hypercalls. > >>> > >>> It should be the toolstack, and only the toolstack, which makes > >>> permissions hypercalls, which in turn will fix a slew of "QEMU doesn't > >>> work when it doesn't have dom0 superpowers" bugs with stubdomains. > >> How much say does the Xen project have over the code > >> in Qemu under hw/xen? I would not be against having libxl > >> do the permissions hypercalls in this case instead of Qemu > >> doing it. My test with Qemu traditional and this patch proves > >> the permission can be granted by libxl instead of the device > >> model. > > Qubes patches libxl and QEMU, and they move the hypercalls to the > > toolstack. They are using linux stubdoms, and I think it works for > > them. > > That still doesn't answer my question - will the Qemu upstream > accept the patches that move the hypercalls to the toolstack? If > not, we have to live with what we have now, which is that the > hypercalls are done in Qemu. Xen-associated people maintain hw/xen code in QEMU, so yes it could be accepted. Maybe it would need to be backwards compatible to have libxl check the QEMU version to decide who makes the hypercall? Unless it is broken today, in which case just make it work. Regards, Jason