[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue with shared information page on Xen/ARM 4.17
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 5 Oct 2023 11:24:52 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IY/ZP+1A8yLjOjA0HPlR3ZxteuI6jDosQ8al0+KNN3E=; b=E0WRvQcJCMcBv9AQX0o2KjDWU047Ulnhw7s04ibO5ljF3WtKCSmG0KQXrA+bbCh4mA4RzyQ3UNXfKT+oCB/vSKosJBn4WJ88f20t2JgfKrnad+YzfVZ/eNXy7307SQdkTb++tskOGIODiYNHqPhLjWfqZa/mnbVGo2Y4m2qTd9Ey9RKz0jBMjX7kBFbV/fZAv8HnRE7+Ko33p4oLFWQIE5XFMb286RPIUxJa8QqMFrHgwg8ZZg+07qvMrahjyqy4g8RGVpnswyAkLKgYxuAxns8XY54Wzwj4Scc5D8TOeYYjOD5yg5Uq61kUNO4I34X7G1bfAhoeAU5ePDYG9oyeew==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P35qldkb8OVcW4Csg5MgjbGBUEVCZAE6591ZqMwKtGWJ7Ga4u/rVx3Al4zCF0fG0WYwk73bGo/K/b+tJ18IJmtDLZIEBPpoRYKh9+rRzNw5h21RClnRwci22s1s8ibgEE372DC7NYyL0taBpTIB3BzTPJL0sKhumTB+6LyIO1QM1dBltCUnLk7Z88Z3JxMYg7rs9RmwqbEJDiBr5q4poEvQdMC7RM7/nGPIA+egyYEceON6oPI/EPN1qDy1hYsl4dtDAz2mxCCitK7JVGxYCry9vWzJqdmt3q+FQkN+o1T4jFttB2McelrSAP4gakypxKGTbCsInqQwUaKV0oHzoUg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Julien Grall <julien@xxxxxxx>, Elliott Mitchell <ehem+xen@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
- Delivery-date: Thu, 05 Oct 2023 09:25:09 +0000
- Ironport-data: A9a23:5KcAequSOZ9UNumYiBRlAHSelufnVMBfMUV32f8akzHdYApBsoF/q tZmKT3SaP/YYWSjfdtwatu3/EsAu8LXnNJmSFNq+yw9HigQ+JbJXdiXEBz9bniYRiHhoOCLz O1FM4Wdc5pkJpP4jk3wWlQ0hSAkjclkfpKlVaicfHg3HFc4IMsYoUoLs/YjhYJ1isSODQqIu Nfjy+XSI1bg0DNvWo4uw/vrRChH4rKq41v0gnRkPaoQ5QeGyiFMZH4iDfrZw0XQE9E88tGSH 44v/JnhlkvF8hEkDM+Sk7qTWiXmlZaLYGBiIlIPM0STqkAqSh4ai87XB9JFAatjsB2bnsgZ9 Tl4ncfYpTHFnEH7sL91vxFwS0mSNEDdkVPNCSDXXce7lyUqf5ZwqhnH4Y5f0YAwo45K7W9yG fMwBytVRR3cudyN/+jnd8dIm58jL47EBdZK0p1g5Wmx4fcOZ7nmGv+PyfoGmTA6i4ZJAOrUY NcfZXx3dhPcbhZTO1ARTpUjgOOvgXq5eDpdwL6XjfNvvy6Pk0osgf60b4C9lt+iHK25mm6Co W3L5SLhCwwyP92D0zuVtHmrg4cjmAuiAt5NTODhqq8CbFu77HIeARkxaWGBkca8jFWfHNBVB 1JP0397xUQ13AnxJjXnZDWju2KNtBMYX9tWEsU55RuLx66S5ByWbkAGUzpAZdoOpMIwAzsw2 TehktPkAH9/vbu9TC+FsLyTqFuaKSUTaGMPeyIAZQ8E+MX45pE+iArVSdRuG7Lzicf6cRn6z iqWtiE4i/MWhNQSyqSg1VndhnSnoZ2hZjAy4gLbT2e09DRTbYSuZ5GrwVXD5PMGJ4GcJnGGu HUHgMGY4Po5EYCWlCeNTeMOG5mk//+AdjbbhDZS84IJ8j2s/zuveN5W6TQnfkNxaJ9bI3nuf VPZvh5X6NlLJny2YKRrYoW3TcM30aznEtejXffRBjZTXqVMmMa81HkGTSatM6rFySDATYlX1 U+nTPuR
- Ironport-hdrordr: A9a23:+0oetq/7uAA6kReqOFhuk+AuI+orL9Y04lQ7vn2ZKSY5TiVXra CTdZUgpHnJYVMqMk3I9uruBEDtex3hHNtOkOss1NSZLW7bUQmTXeJfBOLZqlWNJ8S9zJ856U 4JScND4bbLfDxHZKjBgTVRE7wbsaa6GKLDv5ah85+6JzsaGp2J7G1Ce3am+lUdfng+OXKgfq Dsm/auoVCbCAwqR/X+PFYpdc7ZqebGkZr3CCR2eyLOuGG1/EiVAKeRKWnj4isj
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Oct 04, 2023 at 03:52:54PM -0700, Stefano Stabellini wrote:
> On Wed, 4 Oct 2023, Julien Grall wrote:
> > > > If we want to handle such firmware, I think it would be better if we
> > > > provide
> > > > an hypercall that would return the GFN where it is currently mapped.
> > >
> > > Sure, but such hypercall would be racy, as by the time the gfn is
> > > returned the value could be stale. Adding a replacing and non
> > > replacing XENMEM_add_to_physmap variations would IMO be better.
> > >
> > > Anyway, I don't maintain this, so it's up to you.
> >
> > Bertrand/Stefano, any opinions?
>
> I think we should fix EDK2 to unmap the shared info in all cases as
> that's simpler and the best implementation. What's the value of keeping
> the mapping around when the OS can't find it? Unless you have an idea on
> how the OS could find the location of the existing EDK2 shared info
> mapping.
Indeed, edk2 should unmap the page, and we should fix that.
>
> It is important not to have 2 different behaviors for the same hypercall
> on ARM and x86, especially when the hypercall looks arch-neutral and an
> operating system would reasonably expect to use it in common code.
> Having different behaviors on ARM/x86 is more error prone than having a
> less-than-ideal hypercall implementation.
>
> I agree with Julien that the ARM behavior is the right behavior. Can we
> change the x86 implementation to match ARM somehow?
I'm afraid I don't see how. edk2 is supported on x86, and hence we
cannot simply make a change to the hypervisor that would render all
current versions of edk2 unusable.
> If we do, I guess we would end up breaking legacy EDK2?
Breaking plain edk2, as there's no version of edk2 that currently does
the unmapping?
> Is really the only choice to change the ARM implementation to match the
> x86 implementation?
Unless we want x86 and Arm to diverge in behavior.
I do think the arm behavior is more sane, but I don't think we can
make that change on x86 and simply render all existing versions of
edk2 unusable.
Thanks, Roger.
|
