Re: [Xen-devel] [edk2] [PATCH RFC 03/14] OvmfPkg/XenOvmf.dsc: Introduce XenResetVector

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/01/17 19:49, Laszlo Ersek wrote:
> (1) I think the subject line should just say:
>
>   OvmfPkg: Introduce XenResetVector
>
> (2) New files are added in this patch; you might want to tag them with a
> Citrix copyright notice.
>
> (3) When formatting the next version of this series for posting, please
> pass the "-C --find-copies-harder" options to git-format-patch. Those
> will automatically format each patch in the series as a (copy, diff)
> pair, whenever appropriate, and that way we can compare the changed
> copies more easily against the originals.
>
> On 12/08/16 16:33, Anthony PERARD wrote:
>> Copy of OvmfPkg/ResetVector, with one changes:
>>   - default_cr0: enable cache
> (4) Please mention SEC_DEFAULT_CR0 and the bit that is flipped,
> specifically.
>
>> Xen copy the OVMF code to RAM, there is no need for cache. Also, it
>> makes OVMF slow to start on AMD.
> (5) Wait, is the slow start already an issue (with QEMU/KVM) on AMD?
> Because, in the past, we saw that happen: refer to commit 98f378a7be12.
>
> Are you saying 98f378a7be12 was not entirely right for QEMU/KVM
> (considering recent AMD processors, I guess?)?
>
> Or that the SEC_DEFAULT_CR0 value is not right on AMD only with Xen?

For reasons best known to the original authors of the code, Xen respects
CR0.CD unconditionally for AMD, but respects CR0.CD on Intel only when
the guest has a piece of real hardware passed through, leaving caches
enabled in the general case.

This manifests as a massive performance difference between Intel and AMD.

IMO this behaviour should be fixed in Xen for AMD hardware (to match
Intel), but equally, firmware in a virtual environment has no real
business setting CR0.CD in the first place.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel