[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86emul: de-duplicate scatters to the same linear address
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 18 Oct 2021 14:17:39 +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=7c2nccOL8fMTNlBwSTXOXbyx6anX6RclFw2fsvpwbec=; b=ISNaZAhpqrPec/siITJnFemLAQ7cLXTq6xBOUVR6gGFCx/FLMWsZyIJmFuHjshOb9wJ3bBs6CBNKWynWB5Jg/ag9SIIDmvLAaEu3W/Rr4uuQw+Te4HQTHJbJGAahkJONqhDQUWhPGjvMtg5lC/0pbr4CVmz3q6VwzzzNARnlY5rdX76+aQJkFGXzKlcWXAQUXmU3kTvCMg3RahZ634JtmT9Eznxs8fmF8L2nfhW+wGX4T+aKOixao/n/oQGyRX3d2IjMY5MruxMaHmzE3aS2YH6RZPSRqgO+DnISAMF6Gomg1PMVa93sJIfgfrBAYfqI55QWA3RNMTshOk+Cxps3Uw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mXBEszAAWvwZmRCCgnA8el7pT2LxEsjh7//VQuJ4tt1uLtXpNmOzsm8LtbyyGNGbSz5IXoVeBwsTSZn4HrP3sUS5JTXowkjVNp71kPW0v82kGdB6V0pc76yN1A/wvXJTr1BVmBE9PLdWWyIhoouy+ocDbyirY6CAR/+/F1sd084Laf3wVTa+3T62YB0+bBBYNwcNx3c14Eb6nSol6HH+MV1RvIgQRVrmoTTt7u1L7kFe9C/CQ9+LpBxoz46rdTWA9s6dC/y9Ndgew3GC1b/bPm1zPkrkneNeYaIXonpRbfk0pwFzws4CH0z3y/H68EBDYAN43JCnDEv7PZEn1EXrrw==
- Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Mon, 18 Oct 2021 12:17:53 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 18.10.2021 13:19, Roger Pau Monné wrote:
> On Thu, May 20, 2021 at 03:34:28PM +0200, Jan Beulich wrote:
>> The SDM specifically allows for earlier writes to fully overlapping
>> ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
>> would crash it if varying data was written to the same address. Detect
>> overlaps early, as doing so in hvmemul_{linear,phys}_mmio_access() would
>> be quite a bit more difficult. To maintain proper faulting behavior,
>> instead of dropping earlier write instances of fully overlapping slots
>> altogether, write the data of the final of these slots multiple times.
>
> Is it possible for a later (non duplicated slot) to cause a fault
> ending the instruction without reaching that final slot that contains
> the written data?
Yes, but that's not a problem: Only faults are required to be ordered,
and when a fault occurs guarantees are made only towards lower indices
(read: all lower index writes would have completed, while nothing can
be said about higher indices). All non-faulting writes can go out in
any order (unless there are [partial] overlaps, but afaict that case
still gets dealt with within spec by the proposed new logic).
Jan
|
