[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/x86: p2m: Don't initialize slot 0 of the P2M

  • To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: George Dunlap <george.dunlap@xxxxxxxxxx>
  • Date: Mon, 3 Feb 2020 17:37:17 +0000
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=george.dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Autocrypt: addr=george.dunlap@xxxxxxxxxx; prefer-encrypt=mutual; keydata= mQINBFPqG+MBEACwPYTQpHepyshcufo0dVmqxDo917iWPslB8lauFxVf4WZtGvQSsKStHJSj 92Qkxp4CH2DwudI8qpVbnWCXsZxodDWac9c3PordLwz5/XL41LevEoM3NWRm5TNgJ3ckPA+J K5OfSK04QtmwSHFP3G/SXDJpGs+oDJgASta2AOl9vPV+t3xG6xyfa2NMGn9wmEvvVMD44Z7R W3RhZPn/NEZ5gaJhIUMgTChGwwWDOX0YPY19vcy5fT4bTIxvoZsLOkLSGoZb/jHIzkAAznug Q7PPeZJ1kXpbW9EHHaUHiCD9C87dMyty0N3TmWfp0VvBCaw32yFtM9jUgB7UVneoZUMUKeHA fgIXhJ7I7JFmw3J0PjGLxCLHf2Q5JOD8jeEXpdxugqF7B/fWYYmyIgwKutiGZeoPhl9c/7RE Bf6f9Qv4AtQoJwtLw6+5pDXsTD5q/GwhPjt7ohF7aQZTMMHhZuS52/izKhDzIufl6uiqUBge 0lqG+/ViLKwCkxHDREuSUTtfjRc9/AoAt2V2HOfgKORSCjFC1eI0+8UMxlfdq2z1AAchinU0 eSkRpX2An3CPEjgGFmu2Je4a/R/Kd6nGU8AFaE8ta0oq5BSFDRYdcKchw4TSxetkG6iUtqOO ZFS7VAdF00eqFJNQpi6IUQryhnrOByw+zSobqlOPUO7XC5fjnwARAQABtCRHZW9yZ2UgVy4g RHVubGFwIDxkdW5sYXBnQHVtaWNoLmVkdT6JAlcEEwEKAEECGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4ACGQEWIQTXqBy2bTNXPzpOYFimNjwxBZC0bQUCXEowWQUJDCJ7dgAKCRCmNjwx BZC0beKvEACJ75YlJXd7TnNHgFyiCJkm/qPeoQ3sFGSDZuZh7SKcdt9+3V2bFEb0Mii1hQaz 3hRqZb8sYPHJrGP0ljK09k3wf8k3OuNxziLQBJyzvn7WNlE4wBEcy/Ejo9TVBdA4ph5D0YaZ nqdsPmxe/xlTFuSkgu4ep1v9dfVP1TQR0e+JIBa/Ss+cKC5intKm+8JxpOploAHuzaPu0L/X FapzsIXqgT9eIQeBEgO2hge6h9Jov3WeED/vh8kA7f8c6zQ/gs5E7VGALwsiLrhr0LZFcKcw kI3oCCrB/C/wyPZv789Ra8EXbeRSJmTjcnBwHRPjnjwQmetRDD1t+VyrkC6uujT5jmgOBzaj KCqZ8PcMAssOzdzQtKmjUQ2b3ICPs2X13xZ5M5/OVs1W3TG5gkvMh4YoHi4ilFnOk+v3/j7q 65FG6N0JLb94Ndi80HkIOQQ1XVGTyu6bUPaBg3rWK91Csp1682kD/dNVF3FKHrRLmSVtmEQR 5rK0+VGc/FmR6vd4haKGWIRuPxzg+pBR77avIZpU7C7+UXGuZ5CbHwIdY8LojJg2TuUdqaVj yxmEZLOA8rVHipCGrslRNthVbJrGN/pqtKjCClFZHIAYJQ9EGLHXLG9Pj76opfjHij3MpR3o pCGAh6KsCrfrsvjnpDwqSbngGyEVH030irSk4SwIqZ7FwA==
  • Cc: Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 03 Feb 2020 17:37:35 +0000
  • Ironport-sdr: Eh2yN46dHbtMw3Tu+VITJkpt2r6vmx3d8xhSSQcinJgUyfSQ54zUbGGMb5HYoxUW94SxLvtz3w ucPww3XvgiTGOJBhAKkBUCMw4QqyKwY/y5gEyhL1p+fKIDoe10OpnyhPO3Z6B9gsfKTDIuHex+ 9HhlwBt2PzCkh7Hmb5/yvJ5zOkJKOtqf0gelAgqFo5iYmwP/rWisiYye9BQILvFT41YXTTiWp5 K1BjA4+FFRuLAGrZhLbUtFdpqpdKyMjlfHKEb0PT85Xvll1woIAz5VISg8ZNwxjs4RsmSqTRKB X2k=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 2/3/20 5:22 PM, Julien Grall wrote:
> Hi,
> On 03/02/2020 17:10, George Dunlap wrote:
>> On 2/3/20 4:58 PM, Julien Grall wrote:
>>> From: Julien Grall <jgrall@xxxxxxxxxx>
>>> It is not entirely clear why the slot 0 of each p2m should be populated
>>> with empty page-tables. The commit introducing it 759af8e3800 "[HVM]
>>> Fix 64-bit HVM domain creation." does not contain meaningful
>>> explanation except that it was necessary for shadow.
>> Tim, any ideas here?
>>> As we don't seem to have a good explanation why this is there, drop the
>>> code completely.
>>> This was tested by successfully booting a HVM with shadow enabled.
>>> Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
>>> ---
>>> I don't know for sure if this is going to break a setup. I have tried
>>> HVM guest with hap={0, 1} without any trouble. I am happy to try more
>>> setup if you have any in mind.
>>> If this break a setup, then please describe the setup and I will send a
>>> documentation patch instead.
>> This is a somewhat risky strategy.  Other than code clean-up, is there
>> any advantage to removing this code at the moment?
> If Tim doesn't have an explanation, then we have two solutions:
>    1) Checkin the code and see if that breaks
>    2) Keep code we have no clue why it is there

It is probably early enough in the dev cycle to do this.

Also, it's not clear to me what kind of bug the code you're deleting
would fix.  If you read a not-present entry, you should get INVALID_MFN
anyway.  Unless you were calling p2m_get_entry_query(), which I'm pretty
sure hadn't been introduced at this point.

> I understand that the former is risky, but the latter is not very ideal
> either because if we can't explain the reason now, then it is unlikely
> that we would in the future.
> Regarding the advantage of removing it, I am looking at liveupdate and
> how to keep the P2M around. I am trying to limit the number of "if
> (liveupdate)" within the code. So any cleanup would be beneficial.

OK, thanks.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.