From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gHSsj-0005mR-CO for mharc-grub-devel@gnu.org; Tue, 30 Oct 2018 08:12:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHSsg-0005lD-RZ for grub-devel@gnu.org; Tue, 30 Oct 2018 08:12:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHSsZ-00072H-BX for grub-devel@gnu.org; Tue, 30 Oct 2018 08:12:20 -0400 Received: from mx2.suse.de ([195.135.220.15]:52746 helo=mx1.suse.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gHSsU-0006xI-Ut for grub-devel@gnu.org; Tue, 30 Oct 2018 08:12:12 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id EA5C6B090; Tue, 30 Oct 2018 12:12:08 +0000 (UTC) Subject: Re: [Xen-devel] [PATCH v2 12/18] xen: setup Xen specific data for PVH To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: grub-devel@gnu.org, hans@knorrie.org, phcoder@gmail.com, daniel.kiper@oracle.com, xen-devel@lists.xen.org References: <20181009110317.6022-1-jgross@suse.com> <20181009110317.6022-13-jgross@suse.com> <20181019161015.d6u47uwvvxgiu7lm@mac.bytemobile.com> <20181029125724.mpqrtdiz3waus5w2@mac.bytemobile.com> <84ede595-1603-9f1c-743b-5a03e5dcda04@suse.com> <20181030112312.jfwtxgxb62nv3f3t@mac.citrite.net> From: Juergen Gross Openpgp: preference=signencrypt Autocrypt: addr=jgross@suse.com; prefer-encrypt=mutual; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNHkp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmRlPsLAeQQTAQIAIwUCU4xw6wIbAwcL CQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELDendYovxMvi4UH/Ri+OXlObzqMANruTd4N zmVBAZgx1VW6jLc8JZjQuJPSsd/a+bNr3BZeLV6lu4Pf1Yl2Log129EX1KWYiFFvPbIiq5M5 kOXTO8Eas4CaScCvAZ9jCMQCgK3pFqYgirwTgfwnPtxFxO/F3ZcS8jovza5khkSKL9JGq8Nk czDTruQ/oy0WUHdUr9uwEfiD9yPFOGqp4S6cISuzBMvaAiC5YGdUGXuPZKXLpnGSjkZswUzY d9BVSitRL5ldsQCg6GhDoEAeIhUC4SQnT9SOWkoDOSFRXZ+7+WIBGLiWMd+yKDdRG5RyP/8f 3tgGiB6cyuYfPDRGsELGjUaTUq3H2xZgIPfOwE0EU4xwFgEIAMsx+gDjgzAY4H1hPVXgoLK8 B93sTQFN9oC6tsb46VpxyLPfJ3T1A6Z6MVkLoCejKTJ3K9MUsBZhxIJ0hIyvzwI6aYJsnOew cCiCN7FeKJ/oA1RSUemPGUcIJwQuZlTOiY0OcQ5PFkV5YxMUX1F/aTYXROXgTmSaw0aC1Jpo w7Ss1mg4SIP/tR88/d1+HwkJDVW1RSxC1PWzGizwRv8eauImGdpNnseneO2BNWRXTJumAWDD pYxpGSsGHXuZXTPZqOOZpsHtInFyi5KRHSFyk2Xigzvh3b9WqhbgHHHE4PUVw0I5sIQt8hJq 5nH5dPqz4ITtCL9zjiJsExHuHKN3NZsAEQEAAcLAXwQYAQIACQUCU4xwFgIbDAAKCRCw3p3W KL8TL0P4B/9YWver5uD/y/m0KScK2f3Z3mXJhME23vGBbMNlfwbr+meDMrJZ950CuWWnQ+d+ Ahe0w1X7e3wuLVODzjcReQ/v7b4JD3wwHxe+88tgB9byc0NXzlPJWBaWV01yB2/uefVKryAf AHYEd0gCRhx7eESgNBe3+YqWAQawunMlycsqKa09dBDL1PFRosF708ic9346GLHRc6Vj5SRA UTHnQqLetIOXZm3a2eQ1gpQK9MmruO86Vo93p39bS1mqnLLspVrL4rhoyhsOyh0Hd28QCzpJ wKeHTd0MAWAirmewHXWPco8p1Wg+V+5xfZzuQY0f4tQxvOpXpt4gQ1817GQ5/Ed/wsDtBBgB CAAgFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAlrd8NACGwIAgQkQsN6d1ii/Ey92IAQZFggA HRYhBFMtsHpB9jjzHji4HoBcYbtP2GO+BQJa3fDQAAoJEIBcYbtP2GO+TYsA/30H/0V6cr/W V+J/FCayg6uNtm3MJLo4rE+o4sdpjjsGAQCooqffpgA+luTT13YZNV62hAnCLKXH9n3+ZAgJ RtAyDWk1B/0SMDVs1wxufMkKC3Q/1D3BYIvBlrTVKdBYXPxngcRoqV2J77lscEvkLNUGsu/z W2pf7+P3mWWlrPMJdlbax00vevyBeqtqNKjHstHatgMZ2W0CFC4hJ3YEetuRBURYPiGzuJXU pAd7a7BdsqWC4o+GTm5tnGrCyD+4gfDSpkOT53S/GNO07YkPkm/8J4OBoFfgSaCnQ1izwgJQ jIpcG2fPCI2/hxf2oqXPYbKr1v4Z1wthmoyUgGN0LPTIm+B5vdY82wI5qe9uN6UOGyTH2B3p hRQUWqCwu2sqkI3LLbTdrnyDZaixT2T0f4tyF5Lfs+Ha8xVMhIyzNb1byDI5FKCb Message-ID: <2f5f3875-82e3-d927-1340-ef1ff32cafb8@suse.com> Date: Tue, 30 Oct 2018 13:12:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181030112312.jfwtxgxb62nv3f3t@mac.citrite.net> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 195.135.220.15 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 12:12:24 -0000 On 30/10/2018 12:23, Roger Pau Monn=C3=A9 wrote: > On Mon, Oct 29, 2018 at 03:19:34PM +0100, Juergen Gross wrote: >> On 29/10/2018 13:57, Roger Pau Monn=C3=A9 wrote: >>> On Fri, Oct 19, 2018 at 06:39:50PM +0200, Juergen Gross wrote: >>>> On 19/10/2018 18:10, Roger Pau Monn=C3=A9 wrote: >>>>> On Tue, Oct 09, 2018 at 01:03:11PM +0200, Juergen Gross wrote: >>>>>> Initialize the needed Xen specific data. This is: >>>>>> >>>>>> - the Xen start of day page containing the console and Xenstore ri= ng >>>>>> page PFN and event channel >>>>>> - the grant table >>>>>> - the shared info page >>>>>> >>>>>> Set the RSDP address for the guest from the start_info page passed >>>>>> as boot parameter. >>>>>> >>>>>> Signed-off-by: Juergen Gross >>>>>> --- >>>>>> grub-core/kern/i386/xen/pvh.c | 107 +++++++++++++++++++++++++++++= +++++++++++++ >>>>>> 1 file changed, 107 insertions(+) >>>>>> >>>>>> diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386/x= en/pvh.c >>>>>> index b4933b454..93ed68245 100644 >>>>>> --- a/grub-core/kern/i386/xen/pvh.c >>>>>> +++ b/grub-core/kern/i386/xen/pvh.c >>>>>> @@ -24,6 +24,7 @@ >>>>>> #include >>>>>> #include >>>>>> #include >>>>>> +#include >>>>>> #include >>>>>> =20 >>>>>> struct xen_machine_mmap_entry >>>>>> @@ -39,6 +40,7 @@ static struct { char _entry[32]; } hypercall_pag= e[128] >>>>>> __attribute__ ((aligned (GRUB_XEN_PAGE_SIZE))); >>>>>> =20 >>>>>> static grub_uint32_t xen_cpuid_base; >>>>>> +static struct start_info grub_xen_start_page; >>>>>> static struct xen_machine_mmap_entry map[128]; >>>>>> static unsigned int nr_map_entries; >>>>>> =20 >>>>>> @@ -104,6 +106,36 @@ grub_xen_hypercall (grub_uint32_t callno, gru= b_uint32_t a0, >>>>>> return __res; >>>>>> } >>>>>> =20 >>>>>> +static grub_uint32_t >>>>>> +grub_xen_get_param (int idx) >>>>>> +{ >>>>>> + struct xen_hvm_param xhv; >>>>>> + int r; >>>>>> + >>>>>> + xhv.domid =3D DOMID_SELF; >>>>>> + xhv.index =3D idx; >>>>>> + r =3D grub_xen_hypercall (__HYPERVISOR_hvm_op, HVMOP_get_param, >>>>>> + (grub_uint32_t) (&xhv), 0, 0, 0, 0); >>>>>> + if (r < 0) >>>>>> + grub_xen_early_halt (); >>>>>> + return xhv.value; >>>>>> +} >>>>>> + >>>>>> +static void * >>>>>> +grub_xen_add_physmap (unsigned int space, void *addr) >>>>>> +{ >>>>>> + struct xen_add_to_physmap xatp; >>>>>> + >>>>>> + xatp.domid =3D DOMID_SELF; >>>>>> + xatp.idx =3D 0; >>>>>> + xatp.space =3D space; >>>>>> + xatp.gpfn =3D (grub_addr_t) addr >> GRUB_XEN_LOG_PAGE_SIZE; >>>>>> + if (grub_xen_hypercall (__HYPERVISOR_memory_op, XENMEM_add_to_p= hysmap, >>>>>> + (grub_uint32_t) (&xatp), 0, 0, 0, 0)) >>>>>> + grub_xen_early_halt (); >>>>>> + return addr; >>>>>> +} >>>>>> + >>>>>> static void >>>>>> grub_xen_sort_mmap (void) >>>>>> { >>>>>> @@ -190,12 +222,87 @@ grub_xen_get_mmap (void) >>>>>> grub_xen_sort_mmap (); >>>>>> } >>>>>> =20 >>>>>> +static grub_uint64_t >>>>>> +grub_xen_find_page (grub_uint64_t start) >>>>>> +{ >>>>>> + unsigned int i, j; >>>>>> + grub_uint64_t last =3D start; >>>>>> + >>>>>> + /* Try to find a e820 map hole below 4G. */ >>>>> >>>>> Doing this is kind of dangerous, what if you end up placing somethi= ng >>>>> on top of an MMIO region (either emulated or from a real passthroug= h >>>>> device)? >>>> >>>> Shouldn't those be marked as "Reserved" in the memory map? >>> >>> I don't think BARs are guaranteed to be in areas marked as reserved i= n >>> the memory map. Unless you also scan for PCI devices and make sure >>> there's no device with a BAR in the area you are attempting to >>> populate I think the above is not safe. >> >> So either I can add scanning the PCI bus (which wouldn't be too >> hard IMO), or we require Xen tools to add memory map entries with >> "Reserved" attribute for passed-through PCI device's MMIO-areas >> (we can still do that as PCI pass-through for PVH isn't possible >> yet AFAIK). >=20 > Ideally (and that's kind of far away from what we are now), I would > like to have an interface to request Xen for a range of gfns available > to map stuff in them (grants/foreign mappings/shared page...). That > interface could be a simple hypercall that would return such range, or > an hypercall that could be used to fetch something akin to an > 'extended memory map' with specific Xen information (like such > regions). >=20 > In both cases this requires Xen having a clearer picture of the p2m, > because any of the above solutions cannot rely on scanning the p2m > table in order to figure out what's where. >=20 > So the only change I would request is that if you use a RAM page you > update the memory map stored in Xen to match the new layout, by using > the XENMEM_set_memory_map hypercall. Okay, this is simple. Nevertheless I'm adding the already finished patch for scanning the PCI devices to find MMIO areas. Juergen