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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Feb 5, 2014 at 4:03 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> George, this should go into 4.4 -- there is a security aspect.

Sorry I missed this one -- in spite of obviously being in the 'to'
field up there, I'm pretty sure this never made it to my Citrix inbox
(which puts it in the 'priority' queue more or less).

Release-acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

>
> 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

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