qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] os: don't corrupt pre-existing memory-backend d


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] os: don't corrupt pre-existing memory-backend data with prealloc
Date: Thu, 23 Feb 2017 12:07:20 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Thu, Feb 23, 2017 at 01:05:33PM +0100, Michal Privoznik wrote:
> On 02/23/2017 11:59 AM, Daniel P. Berrange wrote:
> > When using a memory-backend object with prealloc turned on, QEMU
> > will memset() the first byte in every memory page to zero. While
> > this might have been acceptable for memory backends associated
> > with RAM, this corrupts application data for NVDIMMs.
> > 
> > Instead of setting every page to zero, read the current byte
> > value and then just write that same value back, so we are not
> > corrupting the original data.
> > 
> > Signed-off-by: Daniel P. Berrange <address@hidden>
> > ---
> > 
> > I'm unclear if this is actually still safe in practice ? Is the
> > compiler permitted to optimize away the read+write since it doesn't
> > change the memory value. I'd hope not, but I've been surprised
> > before...
> > 
> > IMHO this is another factor in favour of requesting an API from
> > the kernel to provide the prealloc behaviour we want.
> > 
> >  util/oslib-posix.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> > index 35012b9..8f5b656 100644
> > --- a/util/oslib-posix.c
> > +++ b/util/oslib-posix.c
> > @@ -355,7 +355,8 @@ void os_mem_prealloc(int fd, char *area, size_t memory, 
> > Error **errp)
> >  
> >          /* MAP_POPULATE silently ignores failures */
> >          for (i = 0; i < numpages; i++) {
> > -            memset(area + (hpagesize * i), 0, 1);
> > +            char val = *(area + (hpagesize * i));
> > +            memset(area + (hpagesize * i), 0, val);
> 
> I think you wanted:
> 
> memset(area + (hpagesize * i), val, 1);
> 
> because what you are suggesting will overwrite even more than the first
> byte with zeroes.

Lol, yes, I'm stupid.

Anyway, rather than repost this yet, I'm interested if this is actually
the right way to fix the problem or if we should do something totally
different....

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]