All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Юрий Котов" <yury-kotov@yandex-team.ru>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	"wrfsh@yandex-team.ru" <wrfsh@yandex-team.ru>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts
Date: Thu, 4 Apr 2019 10:52:12 +0100	[thread overview]
Message-ID: <20190404095212.GC2678@work-vm> (raw)
In-Reply-To: <156671554283778@vla1-1374b6242101.qloud-c.yandex.net>

* Юрий Котов (yury-kotov@yandex-team.ru) wrote:
> Ping

Is this fixed by Catherine Ho's patch series?

Dave

> 21.03.2019, 19:27, "Yury Kotov" <yury-kotov@yandex-team.ru>:
> > Hi,
> >
> > 19.03.2019, 14:52, "Dr. David Alan Gilbert" <dgilbert@redhat.com>:
> >>  * Peter Maydell (peter.maydell@linaro.org) wrote:
> >>>   On Tue, 19 Mar 2019 at 11:03, Dr. David Alan Gilbert
> >>>   <dgilbert@redhat.com> wrote:
> >>>   >
> >>>   > * Peter Maydell (peter.maydell@linaro.org) 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 / dgilbert@redhat.com / Manchester, UK
> >
> > Regards,
> > Yury
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2019-04-04  9:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03  9:29 [Qemu-devel] [RFC PATCH] QEMU may write to system_memory before guest starts Юрий Котов
2019-04-04  9:52 ` Dr. David Alan Gilbert [this message]
2019-04-04 10:01   ` Yury Kotov
2019-04-17 12:46     ` Yury Kotov
2019-04-17 12:46       ` Yury Kotov
2019-05-14  9:42       ` Yury Kotov
2019-05-17 18:25         ` Eduardo Habkost
2019-05-20  7:50           ` Yury Kotov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190404095212.GC2678@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    --cc=wrfsh@yandex-team.ru \
    --cc=yury-kotov@yandex-team.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.