On Tue, Mar 03, 2015 at 07:13:48PM +0100, Laszlo Ersek wrote: > On 03/03/15 18:34, Alexander Graf wrote: > > On 02/19/2015 11:54 AM, Ard Biesheuvel wrote: > >> This is a 0th order approximation of how we could potentially force > >> the guest > >> to avoid uncached mappings, at least from the moment the MMU is on. > >> (Before > >> that, all of memory is implicitly classified as Device-nGnRnE) > >> > >> The idea (patch #2) is to trap writes to MAIR_EL1, and replace > >> uncached mappings > >> with cached ones. This way, there is no need to mangle any guest page > >> tables. > >> > >> The downside is that, to do this correctly, we need to always trap > >> writes to > >> the VM sysreg group, which includes registers that the guest may write > >> to very > >> often. To reduce the associated performance hit, patch #1 introduces a > >> fast path > >> for EL2 to perform trivial sysreg writes on behalf of the guest, > >> without the > >> need for a full world switch to the host and back. > >> > >> The main purpose of these patches is to quantify the performance hit, and > >> verify whether the MAIR_EL1 handling works correctly. > > > > I gave this a quick spin on a VM running with QEMU. > > > > * VGA output is still distorted, I get random junk black lines in the > > output in between > > * When I add -device nec-usb-xhci -device usb-kbd the VM doesn't even > > boot up > > Do you also have the dirty page tracking patches in your host kernel? I > needed both (and got them via Drew's backport, thanks) and then both VGA > and USB started working fine. Assuming you have the dirty page tracking already, then you're probably missing the fixup to patch 2/3, s/0xbb/0xff/ > > Without the MAIR patches, I got cache-line size "random" corruptions in > the VGA display (16 pixel wide small segments). Without dirty page > tracking, big chunks (sometimes even almost the entire screen) was blank. > > Regarding USB, unless you have both of the patchsets in the host kernel, > the guest will indeed crash early during boot. Gerd confirmed for me > that "usb controller (all uhci/ehci/xhci) pci regions see both read > (status bits) and write (control bits) access". So if there's any > corruption in there, on read, that looks like a malfunctioning piece of > hw for the guest kernel, and in this case it happens to crash. > > > With TCG, both bits work fine. > > Yep. > > Thanks > Laszlo > _______________________________________________ > kvmarm mailing list > kvmarm@xxxxxxxxxxxxxxxxxxxxx > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
