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

Re: [PATCH] x86emul: de-duplicate scatters to the same linear address


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 5 Feb 2021 10:41:33 +0000
  • 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-SenderADCheck; bh=9r8eA83LOvRw2GSa4YUiS/AbKFJ5iGtm51D+Kgfpl7k=; b=fl82bik1cauUlAGeUGpoilhKjkcAyScXWIsxzet5+AEBcP2ShaCuM+1P+hYLKPUmymoj7+7+5hE5c/qiYOALuG8wbkZFWMabHIheur+Bq3XnGXarACOBr+n68udwAPwmVZnaAMJjdh7HYXtctO43xPlGwy3WQZAI1LjPZGJ0PYhidOy/q3KH5zKn+nVd8kXwCUtmBf0fpIORbBpSc2CXX+JwwSAnFapUWGadgSrbJLyutQ+pGv6MIZqztG/zkecz7dgaBsegEnfKdvC0bkmdI/YP5yQL2OS5DGf1LZWfdFAEaY9CQatVAll284addhOGf9Om6e7/HTbhrLt31RpiOw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aJJDe17+6kP789E/r6sj0QSwkL0P2HxyY0/2stM+ZVdVkCOmls18oWQpfyuxtw2fZdGarNFq8kfH0mKqNAfuU02IclI/DaFVKsGaePjH6JRW+3OZwcYzri5px+AZpftCQaZoo1YWq/BN6yNrFaZwjh0PXPQIfWuFwGIiVHT/UkWBROWvBYY9za3f7k4ZqJwohd1y7Sy/mMLN6R9hX+gyxnjRu5GgmGzYJ+K0tRl5GfmN5hjYXnmQNI2ydZpS20MfEbiRQeXe38bZt6u2z+PJSzv99HNhhv4FjfHZk6ODqeW4AMLjOCb0hPmviOfnEFVU8WOLCg6iuKOOwTi7tIEJMw==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 05 Feb 2021 10:42:04 +0000
  • Ironport-sdr: 0KAX4Gk8A28S9aoEOWk17kaKb59PzvH74uUV7OSVFebBtpIiOQ2y6b0ULA92jF+As8Z3HpgkqQ kWYqhzVcleMLBkf0Q1YTNMn/WA1EJCyjv1/GuH9GZYh0ouzp0Tyq7lvdpi+OCC34fEXj8vAX/4 Ni+Jii6R+1Qq9Br0n7TuUOKdYnFCkc9onG8BuKqWHo2Bxg6jvpBHSfjRS4ZGhdtYjWppDDa57p 7UNAoUcvEe4LpC2ev71Ev0nR/j/bnGi3i0Fw/sz4ZQ/Q4J+EwCJDQKMWeC9WDKxzmQZtlSROW1 pSI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10/11/2020 13:26, 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.

Are you saying that there is currently a bug if a guest does encode such
an instruction, and we emulate it?

>
> Note that due to cache slot use being linear address based, there's no
> similar issue with multiple writes to the same physical address (mapped
> through different linear addresses).
>
> Since this requires an adjustment to the EVEX Disp8 scaling test,
> correct a comment there at the same time.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> TBD: The SDM isn't entirely unambiguous about the faulting behavior in
>      this case: If a fault would need delivering on the earlier slot
>      despite the write getting squashed, we'd have to call ops->write()
>      with size set to zero for the earlier write(s). However,
>      hvm/emulate.c's handling of zero-byte accesses extends only to the
>      virtual-to-linear address conversions (and raising of involved
>      faults), so in order to also observe #PF changes to that logic
>      would then also be needed. Can we live with a possible misbehavior
>      here?

Do you have a chapter/section reference?

~Andrew



 


Rackspace

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