[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/shadow: Drop dubious lastpage diagnostic
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Fri, 20 Jan 2023 14:10:38 +0000
- Accept-language: en-GB, en-US
- 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=YCF5JYCTY1lZQy8QZBZuNbS+nNL1neUa/bFFIffrLEU=; b=Isx3XUcavrUgxSuMfkrdH0Lhe657Cgo6ydwVo/fhwFpWqs+ZAmlmI4TiEVK60RoLKiBRyXZwXz9XwbdqFEjTCBIGWJyjrgixm8GkvUd+IcPqterl60/j2p1r+F2MWD0d5fKERJysWCyqyPtDi5xP64jLR/0Z0mpthGcevky+GCcD66WSu6dzTQXAGlKWKxLYH4uJv1xhUNazp+XSmrxI7T0YShBS6idDw4iaMgVTnIjNwXFHQRIICSE5sNWVz2rEVz6HtcSUh0lrmERmMCWXGUdKqtpXwfrpjvQ0rXVbZ+SL/o0g8O0N1TW10fr4H6tL/Oe10tCO4WLY2l76k87I6g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zn+wwwIlJjdZqKgVHsyezYFldOlqljPDRWHtUOH1+soVFanXeYY8I4Wa9aexSPexs+nulAh3FHg5SMj4HTZDl9px+Pm2tpiAA+DJ6v6AYniSsbLHn3MUvzrusHSsfVa2WX8AfTmNltxf03H28zr/eQPfaymtU2z0lvEOpgD8wJwk9zKSyzAfW0v7bO74hL+kHlG66AUS3zIWDAQm9D0gJlEtPG0nwYs68e7nDV8Mj+EZCjjt9h3w/HxdY0BqzlVL6hgFH64K0mFxS1ecDPseJZ7DSIZgPLVI0dR9bRxGiBlkZ3hXZf3VFBg6Z3Rt0FeSum4UUHWc671d8syGVNGuBg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 20 Jan 2023 14:11:14 +0000
- Ironport-data: A9a23:WHCF367HQET6zrrQxGIefwxRtAnGchMFZxGqfqrLsTDasY5as4F+v jAdXTyHb63fY2b2KtFwa9u0oUkGvZLSzINqQAc6r39kHi5G8cbLO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRGvynTraBYnoqLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMSaM1K+s9JOGjt8B5mr9VU+45wehBtC5gZlPakR5AeE/5UoJMl3yZ+ZfiOQrrZ8RoZWd 86bpJml82XQ+QsaC9/Nut4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5iXBYoUm9Fii3hojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5m3 6U0ChcEX0y6raGE+6KFdsBO2O4tFZy+VG8fkikIITDxK98DGMqGaYOaoNhS0XE3m9xEGuvYa 4wBcz1zYR/cYhpJfFAKFJY5m+TujX76G9FagAvN+exrvC6OkUooj+KF3Nn9I7RmQe18mEqCq 32A1GP+GhwAb/SUyCaf82LqjejK9c/+cNNISOflpq436LGV7lczGkUXf3S3mqOGtFKzGP5SF XIlojV7+MDe82TuFLERRSaQonSJoxodUNp4CPAh5UeGza+8yxmdLngJSHhGctNOnNM3QBQ62 1nPmMnmbRR/vbvQRX+D+7O8qTKpJTNTPWIEfTUDTwYO/5/kuo5bs/7UZtNqEarwhNulHzj1m mqOtHJn2O9VitMX3aKm+1yBmyirupXCUg8y4EPQQ36h6QR6IoWiYuRE9GTm0BqJF67BJnHpg ZTOs5P2ADwmZX1VqBGwfQ==
- Ironport-hdrordr: A9a23:k9uoOKzKUUByodcmNgIKKrPw6L1zdoMgy1knxilNoHxuH/Bw9v re+cjzsCWftN9/Yh4dcLy7VpVoIkmsl6Kdg7NwAV7KZmCP1FdARLsI0WKI+UyCJ8SRzI9gPa cLSdkFNDXzZ2IK8PoTNmODYqodKNrsytHWuQ/HpU0dKT2D88tbnn9E4gDwKDwQeCB2QaAXOb C7/cR9qz+paR0sH7+G7ilsZZmkmzXT/qiWGCI7Ow==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZLMTJYmmsHN9huU+OUU/Zg+9KvK6nR7kAgAAQrgA=
- Thread-topic: [PATCH] x86/shadow: Drop dubious lastpage diagnostic
On 20/01/2023 1:10 pm, Jan Beulich wrote:
> On 20.01.2023 12:45, Andrew Cooper wrote:
>> This is a global variable (actually 3, one per GUEST_PAGING_LEVEL), operated
>> on using atomics only (with no regard to what else shares the same
>> cacheline),
>> which emits a diagnostic (in debug builds only) without changing any program
>> behaviour.
>>
>> Based on read-only p2m types including logdirty, this diagnostic can be
>> tripped by entirely legitimate guest behaviour.
> Can it? At the very least shadow doesn't use p2m_ram_logdirty, but "cooks"
> log-dirty handling its own way.
>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
Thanks.
> with the last sentence above corrected (if need be: removed).
I can remove it, but I feel as if there ought to be something there.
The other RO types are ram_ro, grant_map_ro and ram_shared. shared has
hopefully been unshared before getting to this point, while the other
two have unclear semantics (as neither exist in real systems).
Writing to something which is actually a ROM either does silent discard,
or #MC.
Read-only grants really ought to #PF, but I bet this ABI change between
PV and HVM guests wasn't noticed because I'm not aware of any common
uses of read-only grants.
~Andrew
|
