[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before gues
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts |
Date: |
Fri, 17 May 2019 15:25:25 -0300 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
My memory is failing here: do we still need to fix a bug where
there are unexpected writes to system_memory, or this is just a
request to include a mechanism to help us detect those cases in
the future?
On Tue, May 14, 2019 at 12:42:14PM +0300, Yury Kotov wrote:
> Ping ping
>
> 17.04.2019, 15:46, "Yury Kotov" <address@hidden>:
> > Ping
> >
> > 04.04.2019, 13:01, "Yury Kotov" <address@hidden>:
> >> I saw Catherine Ho's patch series and it seems ok to me, but in this RFC
> >> I asked
> >> about a way how to detect other writes which may not be covered by
> >> particular
> >> fixes.
> >> Perhaps this is excessive caution...
> >>
> >> Regards,
> >> Yury
> >>
> >> 04.04.2019, 12:52, "Dr. David Alan Gilbert" <address@hidden>:
> >>> * Юрий Котов (address@hidden) wrote:
> >>>> Ping
> >>>
> >>> Is this fixed by Catherine Ho's patch series?
> >>>
> >>> Dave
> >>>
> >>>> 21.03.2019, 19:27, "Yury Kotov" <address@hidden>:
> >>>> > Hi,
> >>>> >
> >>>> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <address@hidden>:
> >>>> >> * Peter Maydell (address@hidden) wrote:
> >>>> >>> On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
> >>>> >>> <address@hidden> wrote:
> >>>> >>> >
> >>>> >>> > * Peter Maydell (address@hidden) wrote:
> >>>> >>> > > I didn't think migration distinguished between "main memory"
> >>>> >>> > > and any other kind of RAMBlock-backed memory ?
> >>>> >>> >
> >>>> >>> > In Yury's case there's a distinction between RAMBlock's that
> >>>> are mapped
> >>>> >>> > with RAM_SHARED (which normally ends up as MAP_SHARED) and
> >>>> all others.
> >>>> >>> > You can set that for main memory by using -numa to specify a
> >>>> memdev
> >>>> >>> > that's backed by a file and has the share=on property.
> >>>> >>> >
> >>>> >>> > On x86 the ROMs end up as separate RAMBlock's that aren't
> >>>> affected
> >>>> >>> > by that -numa/share=on - so they don't fight Yury's trick.
> >>>> >>>
> >>>> >>> You can use the generic loader on x86 to load an ELF file
> >>>> >>> into RAM if you want, which would I think also trigger this.
> >>>> >>
> >>>> >> OK, although that doesn't worry me too much - since in the
> >>>> majority
> >>>> >> of cases Yury's trick still works well.
> >>>> >>
> >>>> >> I wonder if there's a way to make Yury's code to detect these
> >>>> cases
> >>>> >> and not allow the feature; the best thing for the moment would
> >>>> seem to
> >>>> >> be to skip the aarch test that uses elf loading.
> >>>> >
> >>>> > Currently, I've no idea how to detect such cases, but there is an
> >>>> ability to
> >>>> > detect memory corruption. I want to update the RFC patch to let
> >>>> user to map some
> >>>> > memory regions as readonly until incoming migration start.
> >>>> >
> >>>> > E.g.
> >>>> > 1) If x-ignore-shared is enabled in command line or memory region
> >>>> is marked
> >>>> > (something like ',readonly=on'),
> >>>> > 2) Memory region is shared (,share=on),
> >>>> > 3) And qemu is started with '-incoming' option
> >>>> >
> >>>> > Then map such regions as readonly until incoming migration finished.
> >>>> > Thus, the patch will be able to detect memory corruption and will
> >>>> not affect
> >>>> > normal cases.
> >>>> >
> >>>> > How do you think, is it needed?
> >>>> >
> >>>> > I already have a cleaner version of the RFC patch, but I'm not sure
> >>>> about 1).
> >>>> > Which way is better: enable capability in command line, add a new
> >>>> option for
> >>>> > memory-backend or something else.
> >>>> >
> >>>> >> Dave
> >>>> >>
> >>>> >>> thanks
> >>>> >>> -- PMM
> >>>> >> --
> >>>> >> Dr. David Alan Gilbert / address@hidden / Manchester, UK
> >>>> >
> >>>> > Regards,
> >>>> > Yury
> >>> --
> >>> Dr. David Alan Gilbert / address@hidden / Manchester, UK
--
Eduardo