[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180409032601.GA1648@stefanha-x1.localdomain>
Date: Mon, 9 Apr 2018 11:26:01 +0800
From: Stefan Hajnoczi <stefanha@...il.com>
To: Pankaj Gupta <pagupta@...hat.com>
Cc: David Hildenbrand <david@...hat.com>, kwolf@...hat.com,
haozhong zhang <haozhong.zhang@...el.com>, jack@...e.cz,
xiaoguangrong eric <xiaoguangrong.eric@...il.com>,
kvm@...r.kernel.org, riel@...riel.com, linux-nvdimm@...1.01.org,
mst@...hat.com, ross zwisler <ross.zwisler@...el.com>,
linux-kernel@...r.kernel.org, qemu-devel@...gnu.org,
hch@...radead.org, pbonzini@...hat.com, stefanha@...hat.com,
niteshnarayanlal@...mail.com, marcel@...hat.com,
imammedo@...hat.com, dan j williams <dan.j.williams@...el.com>,
nilal@...hat.com
Subject: Re: [Qemu-devel] [RFC] qemu: Add virtio pmem device
On Thu, Apr 05, 2018 at 08:09:26AM -0400, Pankaj Gupta wrote:
> > Will this raw file already have the "disk information header" (no idea
> > how that stuff is called) encoded? Are there any plans/possible ways to
> >
> > a) automatically create the headers? (if that's even possible)
>
> Its raw. Right now we are just supporting raw format.
>
> As this is direct mapping of memory into guest address space, I don't
> think we can have an abstraction of headers for block specific features.
> Or may be we can get opinion of others(Qemu block people) it is at all possible?
memdev and the block layer are completely separate. The block layer
isn't designed for memory-mapped access.
I think it makes sense to use memdev here. If the user wants a block
device, they should use an emulated block device, not virtio-pmem,
because buffering is necessary anyway when an image file format is used.
Stefan
Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)
Powered by blists - more mailing lists