qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).