[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/3] x86/mem_sharing: option to enforce fork starting with empty p2m
- To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 30 Mar 2022 08:46:58 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=YmTMmwd00tZOgY9P/GKREsDxPKBNgOei6ZTa1vvjE94=; b=HMRm+if7EgQATILeEOzaTif+xtuhMieGRi+8bpbXuPAdVPj91eLEgLoA5AFaa2P/AEFwtoLswxB2cNKLDoIWEe/gb40rO69wsRJzEYfz652KJajdrL6yTToyjZDLAOI0h0C1OZK/tI8SEaNgILWXaeffs4OGKHMa9S2WQx1GIIuzQFLqSx2fWVgYT446G7dt4Abc7nMMndG69CCB36BlJnZcEdiQowGuG2EiEM8A8ti5vIqMV/kIVurKb+IzTmHhE+7kFQGjLrlzrY0kjVBKqxhfuCCFM9BeIKRcJM8tvR+iOTc+K1qrBdEQU9ffUudr6oUU06xviRUDdOpOLl8nng==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dsoi6STj1NVlhIm/F5yl0CEjWXQGyUnc6OflTA0GHweLtMezsdCXUrGVUvfPBiy7D1rgSqKmWNZn1QF7UOnykER7h6FrzpqFW3ZsWfCjU4eLgM41Zj67AJ5u26nNsniQRyaemOHgi6FM12NG4xk7Ik0OM9mgi9AjmKBusVbsAOaAnWeTlkuxwSNgabpMPtxr21N3Eycc4XTdPs8RBOzB7EtXIKLDgGFOF/Gb70zQN4RgCzHy2yFBIynGOakI4LeJGODprEJN6pmv2Rgqav3XqnMnCZmW5YySNpm73yAtW9eXB2OWmu3ScLgzuc1tGZ4pbVw8G+lVxwEeFSgQQDddsQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <JGross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 30 Mar 2022 06:47:18 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 29.03.2022 18:10, Tamas K Lengyel wrote:
> On Tue, Mar 29, 2022 at 11:42 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 29.03.2022 16:03, Tamas K Lengyel wrote:
>>> Add option to the fork memop to enforce a start with an empty p2m.
>>> Pre-populating special pages to the fork tend to be necessary only when
>>> setting
>>> up forks to be fully functional with a toolstack or if the fork makes use of
>>> them in some way. For short-lived forks these pages are optional and
>>> starting
>>> with an empty p2m has advantages both in terms of reset performance as well
>>> as
>>> easier reasoning about the state of the fork after creation.
>>
>> I'm afraid I don't consider this enough of an explanation: Why would these
>> page be optional? Where does the apriori knowledge come from that the guest
>> wouldn't manage to access the vCPU info pages or the APIC access one?
>
> By knowing what code you are fuzzing. The code you are fuzzing is
> clearly marked by harnesses and that's the only code you execute while
> fuzzing. If you know the code doesn't use them, no need to map them
> in. They haven't been needed in any of the fuzzing setups we had so
> far so I'm planning to be this the default when fuzzing.
But isn't it the very nature of what you do fuzzing for that unexpected
code paths may be taken? By not having in place what is expected to be
there, yet more unexpected behavior might then result.
Plus - how do you bound how far the guest executes in a single attempt?
Jan
|
