[Xen-devel] [PATCH 0/5 v5] xen/arm: fix guest builder cache cohenrency (again, again)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

George gave a release ack to v3.

Both 32 and 64 bit have survived ~10,000 boots with v4.

Changes in v5:
        avoid get_order_from_pages and just use 1<<MAX_ORDER
    
    s/sync_page_to_ram/flush_page_to_ram/g
    
    remove hard tab, add an emacs magic block

Changes in v4:
                make sure to actually invalidate the cache, not just
                clean it
                
                rename existing cache flush functions to avoid catching
                me out that way again.

                switch to using a start + length in the domctl interface
                
Changes in v3:
        s/cacheflush_page/sync_page_to_ram/
                    
        xc interface takes a length instead of an end
                    
        make the domctl range inclusive.
                    
        make xc interface internal -- it isn't needed from libxl
        in the current design and it is easier to expose an
        interface in the future than to hide it.
                
Changes in v2:
        Flush on page alloc and do targeted flushes at domain build time
        rather than a big flush after domain build. This adds a new call
        to common code, which is stubbed out on x86. This avoid needing
        to worry about preemptability of the new domctl and also catches
        cases related to ballooning where things might not be flushed
        (e.g. a guest scrubs a page but doesn't clean the cache)

This has done 12000 boot loops on arm32 and 10000 on arm64.

Given the security aspect I would like to put this in 4.4.

Original blurb:

On ARM we need to take care of cache coherency for guests which we have
just built because they start with their caches disabled.

Our current strategy for dealing with this, which is to make guest
memory default to cacheable regardless of the in guest configuration
(the HCR.DC bit), is flawed because it doesn't handle guests which
enable their MMU before enabling their caches, which at least FreeBSD
does. (NB: Setting HCR.DC while the guest MMU is enabled is
UNPREDICTABLE, hence we must disable it when the guest turns its MMU
one).

There is also a security aspect here since the current strategy means
that a guest which enables its MMU before its caches can potentially see
unscrubbed data in RAM (because the scrubbed bytes are still held in the
cache).

As well as the new stuff this series removes the HCR.DC support and
performs two purely cosmetic renames.

Ian.



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