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 ACBD7C5DF81 for ; Tue, 18 Aug 2026 17:15:53 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1394371.1633190 (Exim 4.92) (envelope-from ) id 1wwNPK-00046v-WD; Tue, 18 Aug 2026 17:15:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1394371.1633190; Tue, 18 Aug 2026 17:15:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wwNPK-00046o-Rz; Tue, 18 Aug 2026 17:15:26 +0000 Received: by outflank-mailman (input) for mailman id 1394371; Tue, 18 Aug 2026 17:15:25 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wwNPJ-00046i-Pz for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 17:15:25 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wwNPI-0005Y0-Rh for xen-devel@lists.xenproject.org; Tue, 18 Aug 2026 19:15:24 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a849312-2eae-0a2a0a5409dd-0a2a4507b9fa-34 for ; Tue, 18 Aug 2026 19:15:24 +0200 Received: from [98.137.64.83] (helo=sonic305-20.consmr.mail.gq1.yahoo.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a84932a-b4ea-0a2a45070019-62894053a821-3 for ; Tue, 18 Aug 2026 19:15:23 +0200 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 18 Aug 2026 17:15:21 +0000 Received: by hermes--production-bf1-54b5569bdc-h5zdx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 98c40eed43962414fb5e048669f343c4; Tue, 18 Aug 2026 17:15:19 +0000 (UTC) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=a2048 header.d=aol.com header.i="@aol.com" header.h="Date:Subject:From:To:Cc:References:In-Reply-To" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1787073321; bh=ww0do9RIpWZpsVbpNSFOhezYk+OgminhDdsrY20XsMg=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From:Subject:Reply-To; b=GaNh19QUvPFaQzjGq8mnc2VsGg11xf0nVMfhLsjLDYKmOc0h3V91ozijb2eC4o0yn1C8qkGfWw3R86GNTC0AkabW8RUdvBrpSaR5926j0//2ZsMeSTiWoV7KHSX4mdxk7wcD1DQUevi4RngGwzhzj65gjd39zarlbpY7XRP/mn/rhrH1aeQxQE3ZYiXr1dH1i7I3V1OvA+mcaH8XUE0oODYvU6YGa8w1h4mkuPUg9HfkRYSLG77MLR7HsxoT/lFOO5hUV0zCaPmh60YlpiC34BE/0XYMekcN4V+oxnDatdlSb6Fe7fUn46ZPyLZOIU/7ATgzjVe0fwS2gdTv8FbJvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787073321; bh=v+4Qi5BEw41TP/0I2vqdj5LVgeJipweToZ70c0VID5v=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=H8FrYQlVToUpnFbShzXFwcfffrsuVhtxeJPz4YGDLDxO37eQ2/Od3KHbnHp+QebBdDO/VSyrKBpcGuLJJsT28GD2pKrL6GIYmyagIrmOqlEtVWPCjCkh/VEmexn1FwsVCSJXI2A964Atzk+Z6CtXf/Yd0F6g6lusaDcl+VFMXzN5cnmLRXdFegAP/Drc/tPcv6eSeZ0tc/vjJ9Uudn0px2xLmhAVaz3rRD17kUGsD1LwC87Z6rYeIoV+19hnQk04OATOdaAxTOJVmVciMMx84yMJjan098aCwDb85NGiwacp3ipbd+TjeFYDz2s21cEyxs/Pv1SU5jM/Og7VeK7Sfg== X-YMail-OSG: E6ofAT0VM1n9r71xfRntP8iTNGo8uLmyyFcsFXM3pVg29_OofBq.fDJ1ed6s_lG CMLyu2VGGiaPkvmlycrT8I2unAV5dSg2v2gqoBBAuQmeAUkAeZBvrT7fuJiv6u7o.ITpdBFFOGMJ BFrwrh6L8M9ggcVmez7q_f0kU6KXdtLD3yjYPaOqyTVFrzEDlAvYax9fxdIcBygJz00P57yDk5ff RdAyiRcxXIuIq3BAXnPwxOKTliuLGsNazlZV2ZyRAAb5PVB5eScGMXfmfSkoKH_mEVZ0B9qXwpBo JDcMplMaRmmpym3jQo8SJdodeZKubLDYxDws00vKQIBkao0Sw8Jjw2a67H7gVd2z09m48ZkC5Ssa 4bHW9FoxL.tM4Eg8qfZ1oIL3t03vblVDjbMlir1wWJ0WOpsAtQp3Yb6ndOC3733h4wF4yhEMrykw frIQs7zYpXHwrOYhcVKAC4nDawrOiXkmvCiBYbQf5CvJnuKoo9Rm0ntkmoWKc2GPRrTApKMTFGmB KiSVku2ItFIggtgPsk7PazlFiA5.DRAUGrRnqvsbivRY4s2DVaqLUuRH1eleGt4RCGYEpbvosX7z V4ttapJHEgFOUpgvOpzrC_cPKUnuPHlnm3y3SnnWw3thp45NpA9jwXW.2IgXKQ1wTVLQyc0NAaSM 28GZtu6S0sLgPfGuYLLb2XKw8W01yba6BEjr0PjF04n3UdCSxLytjkuURtyC.QhyFS8jecZKAdkg P3aGynupAAtqlmooZ0SLE_9TiMkJqYPhCprxL_r7ygxXE1rLIxgOT0ktkGi5WVUbvHrdv9PW_PUS ZrySvs9KH2wwlOdAFEqsP6CyipgS6JshkpjWbE9xS1Y.B2qPgihvFdDGD_1Wz6Fku2BTgev06N0w .uPyoOv5MXAA3h0ZQhLNnTz5o._BCSTTUh3OBt9AMTyBd037roaQEnIh5D6WadlNHkREFa.6sAi6 a3UG6rfd0.kjA1tIIgegNGNZWdQogobFVzSNM9H4Qpok2bXdI.J.yiwT1f0SLxL0mABhedn0KxPS Alt0Dl34KoXAuvZlCodGFo9uQ3r_0XWxbKOxSAkGaQ3NZWQkjHtTjDnjeybYs8w2CZEtTbgnvLky 7MM0Ridv22E9zHQYgTVHzOHQ4UHa7e1fZb48i2xLiw4D2XJ10KR9WNyeoBbSZGmY1QQ_yZ6PcUmp 8w4.qboEupKschHuEyPwJzYqLrfgW1hnomHzWRzQ5aw8yCqhOE1j7nPaGSFGuDuWrHf6RaYGLt3K zhMF554qAB_UssU_7NAYBZ2y0aRemhFdTgaiPrQNmHWoE_8F2EscFhWmghiMSUXw0FzyWm2YeOQJ RU3shSA63BXJk4oin0fPq1UmlXcQPgVsDyekqrqa8PxZijZFEeH9UN5fjR3js8j35783LWg6Mht6 AReQFRIyJDyEIqEQpPZyjjI.hrV8wAkNL8F8mcboiM9qB1exOTKwANVMZwF8n2w_7dS5x3xrOagw iXKwDFHjJWleZfUnz0aI1.SjWuo06PZWiMGIxjcA8r05lMMwW8fPobbY84VF1sNLg6vzhBZAUAAt O22QSOw3GipDrZN.wsqPxdI2YFOlS8B1Zqx5Hb9B6.320hGRtWvaT4wLDflAIEXrk6kRIFymMNYD gEidBndyjIqLFSPncyuwhTd82S04JF1L48M0q.SKGQdwe9ERIlUCi1LHqpxWyPRUYeDrb2NvLaXM xVg.BBGlHGcMyPuEIQEK7R0BfSrwtt_Lid3287KqYy9MEEzNQPcncUVB.qwNbtl7CFD1031LVgq5 60pwaFYEm8jOpvRiU5IJjaDoed1WGMtKRMBeGObvXrRZy0u_8ygMgHtGmlMGV5sknK5MkMiPUkLE Ma82oJ_H2APgSNCLMqhF.h8jbS64YuYCRo53ILHhAeFSB0v9WisIBaZCig3EDdPn1rUw_8nG5121 X2orfiUYj5frjATJoJl1E1vYl4VFrqwRPLLQwiqwgoGUZoLNmp_pJ4Qb4anc8x8eUEdbsiqU8vVh Wu0Mce8CiqBCxgOOKeSnnmGRl0fqmlkoeUEYFS5_1EPtoL8so2Y1EvTmOWBEUjqmwN4xxJ.xg5Q. 4QLD71532U6lLj4n46CDzKXCd7mpw5fZmPNJEJKhgYyDV9EKdz9N.Tr09rDXxFmC0SdiLHvWjoov pZXdWBtdggJCzZmIC6s3MpHTp82wa2cx5gJKYFim_cJ4EXM8RaDgRD81jEqfQ2XqNJdo76usFuvf qTzdOqzp8PLJjNpeRgfURzVcQTx_SNffSnBfyDL3GOtpEQgY- X-Sonic-MF: X-Sonic-ID: bfde24b5-fcdf-40ac-8182-a0be452d90a5 Message-ID: Date: Tue, 18 Aug 2026 13:15:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] tools/hvmloader: implement Intel IGD extended VBT support From: Chuck Zmudzinski To: Jan Beulich Cc: qemu-devel@nongnu.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , Tomita Moeko , xen-devel References: <20260802050824.10554-1-brchuckz.ref@aol.com> <20260802050824.10554-1-brchuckz@aol.com> <2110d4b7-ae37-47aa-99be-ab59e16f6167@suse.com> <67579eba-e222-41dd-84bf-8440d2eaf2a9@netscape.net> <02a7dc18-4184-4e86-84cb-121769187f71@suse.com> <1858e8e6-73fa-4017-93e2-c733fbf0ec8d@aol.com> <6ecf80ef-2f0e-44fb-beab-dbcf065a4431@suse.com> <4c58bda6-e9ed-438d-b96e-feda74a6c4c7@suse.com> <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com> Content-Language: en-US In-Reply-To: <31a5870f-2a4d-4dc0-af9c-f0567e0f6fb3@aol.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.26254 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol X-purgate-ID: tlsNG-ef75cf/1787073324-362C4AE4-CF58CDBC/0/0 X-purgate-type: clean X-purgate-size: 8751 On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote: > On 8/18/2026 8:18 AM, Jan Beulich wrote: >> On 18.08.2026 13:52, Chuck Zmudzinski wrote: >>> On 8/18/2026 3:17 AM, Jan Beulich wrote: >>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote: >>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote: >>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote: >>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote: >>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote: >>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote: >>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote: >>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote: >>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote: >>>>>>>>>>>>> -- snip -- >>>>>>>>>>>>> + /* >>>>>>>>>>>>> + * Write rvda_host as 2 successive 32-bit values >>>>>>>>>>>>> + * to communicate location of the VBT to the device >>>>>>>>>>>>> + * model. If rvda_host is not 0, The device model >>>>>>>>>>>>> + * unmaps the OpRegion and eventually maps the VBT >>>>>>>>>>>>> + * after we also write the guest address where the >>>>>>>>>>>>> + * VBT will be mapped. >>>>>>>>>>>>> + * >>>>>>>>>>>>> + * If we send rvda_host = 0 to the device model, it >>>>>>>>>>>>> + * will assume we do not need OpRegion 2 support and >>>>>>>>>>>>> + * it will not unmap the OpRegion. >>>>>>>>>>>>> + */ >>>>>>>>>>>>> + pci_writel(vga_devfn, PCI_INTEL_OPREGION, >>>>>>>>>>>>> + (uint32_t)(rvda_host & 0xfffffffful)); >>>>>>>>>>>>> + unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32; >>>>>>>>>>>>> + pci_writel(vga_devfn, PCI_INTEL_OPREGION, >>>>>>>>>>>>> + (uint32_t)rvda_host_upper_32); >>>>>>>>>>>> >>>>>>>>>>>> Why would you need to communicate a host property to the DM? >>>>>>>>>>> >>>>>>>>>>> The DM cannot access the host rvda value because it is only accessible >>>>>>>>>>> from the host kernel, and the DM is only a user-space process on the host. >>>>>>>>>> >>>>>>>>>> I don't follow this: Anything the guest can access should also be accessible >>>>>>>>>> by its DM. >>>>>>>>> >>>>>>>>> I think the host OpRegion is not currently accessible by the DM. >>>>>>>> >>>>>>>> Can you explain to me how the region becomes accessible to the guest? >>>>>>>> That would then (hopefully) help me understand why the DM would not have >>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to a >>>>>>>> guest are also assigned to its DM. >>>>>>> >>>>>>> Currently, in the device model (Qemu) we have: >>>>>>> >>>>>>> ret = xc_domain_memory_mapping(xen_xc, xen_domid, >>>>>>> (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT), >>>>>>> (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), >>>>>>> XEN_PCI_INTEL_OPREGION_PAGES, >>>>>>> DPCI_ADD_MAPPING); >>>>>>> >>>>>>> That statement is in the igd_write_opregion(...) function in the >>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source. >>>>>>> >>>>>>> If I understand our current implementation correctly, this statement >>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined >>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES >>>>>>> in hvmloader code). >>>>>> >>>>>> No, it introduces mappings of those pages into the guest's P2M. >>>>>> >>>>>>> I don't think this statement makes the host OpRegion >>>>>>> accessible to the device model, though, so I think, if I understand your >>>>>>> comment in an earlier about my patch resulting in what you called a "layering >>>>>>> violation" correctly, that our current implementation is also guilty of this >>>>>>> same kind of "layering violation." >>>>>> >>>>>> That code, if it can be successfully executed, indeed doesn't grant any >>>>>> permissions (to the DM or the guest). Instead it proves that the DM has the >>>>>> needed permissions to access the pages itself. >>>>> >>>>> So, are you saying it should be possible, without any patches to either Xen or >>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how? >>>>> >>>>> I think I could implement what you proposed in an earlier message and do >>>>> all (or most) of this in the DM instead of here in hvmloader: >>>>> >>>>>> The more correct thing to do might be for the DM to >>>>>> put in place a copy before the guest (i.e. hvmloader) even gains control. >>>>>> (How in turn the DM would learn of the contents of the opregion is a >>>>>> separate question then.) >>>>> >>>>> Actually, when I was developing this patch, I tried first to do it that >>>>> way, but the problem was, I could not find a way to get a pointer to the >>>>> host OpRegion in Qemu. >>>>> >>>>> So, how can I get a pointer to the host OpRegion in Qemu? >>>> >>>> You don't ask me this question, do you? >>> >>> Are you offended I asked this question? If so, I am sorry. You make me >>> afraid to ask it again so I will not do so unless you permit to do so >>> again. >> >> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a >> qemu person, and I never have been. I can't really help much there. >> >>> All I can say is that surely qemu >>>> has an existing way to map (host) physical memory; see e.g. how >>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a >>>> device. "Bogusly" there because that's another layering violation. Plus >>>> (independently) there and here there's the issue of how to accomplish >>>> things when not running in Dom0, or when running de-privileged in Dom0. >>> >>> Well, that only proves Qemu *might* be able to access the MSI-X table of >>> a device, that is, if the calls to open /dev/mem and mmap it succeed. >>> Why is the MSI-X table all of the sudden relevant? Even if Qemu >>> can access the MSI-X table of some device, that does not prove that >>> Qemu can access the host OpRegion of an Intel IGD. So I think my point >>> still stands: I still don't see proof that it is possible for Qemu >>> to get a pointer to the host OpRegion without any patches to the current >>> implementations of Xen and the Linux kernel. >> >> The MSI-X table (and it being accessible to qemu) is the best analogy I >> could come up with, as that's one tiny area of qemu that I know at least >> a little. >> >> From a Xen perspective, this analogy should be sufficient: All you need >> from Xen is for it to permit to establish mappings of the underlying page. >> As I've pointed out when commenting on a code fragment you presented, the >> DM (domain) looks to have permission. Everything else is a matter of >> establishing such a mapping. There the MSI-X table code may also guide >> you. (Sadly it may also misguide you, since (a) I don't know whether it's >> appropriate to do things this way in qemu, and since (b) it is, as said, >> imo a layering violation.) > > I agree that accessing the host /dev/mem directly is cringy. I would not > really want to do it that way for the host OpRegion. I looked at the current mainline Linux kernel code about access to memory using /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to ordinary system RAM but allows access to what the kernel developers call non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file in the Linux source code: > * On x86, access has to be given to the first megabyte of RAM because that > * area traditionally contains BIOS code and data regions used by X, dosemu, > * and similar apps. Since they map the entire memory range, the whole range > * must be allowed (for mapping), but any areas that would otherwise be > * disallowed are flagged as being "zero filled" instead of rejected. > * Access has to be given to non-kernel-ram areas as well, these contain the > * PCI mmio resources as well as potential bios/acpi data regions. So I think things like the MSI-X table and the OpRegion would qualify for /dev/men access even with CONFIG_STRICT_DEVMEM set, so after seeing this I expect I could get a pointer to the OpRegion running in Qemu using /dev/mem and mmap, as long as it is running in dom0 with root privileges. But as I said earlier, I agree that /dev/mem and mmap does not feel like the right way to do it. So I would like to come back to something else you said in an earlier message: > (How in turn the DM would learn of the contents of the opregion is a separate > question then.) Let me phrase the question like this: How could the DM gain access to the contents of the OpRegion, and for that matter, also the contents of the MSI-X table, without also committing a layering violation? Chuck