On 12.08.23 08:21, ThinerLogoer wrote:
At 2023-08-11 22:31:36, "Peter Xu" wrote:
On Fri, Aug 11, 2023 at 01:49:52PM +0800, ThinerLogoer wrote:
At 2023-08-11 05:24:43, "Peter Xu" wrote:
On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
I think we have the following options
On Fri, 11 Aug 2023 17:26:24 +0200
David Hildenbrand wrote:
[...]
> Nowadays, "-mem-path" always defaults to MAP_PRIVATE. For the original
> hugetlb use case, it's still good enough. For anything else, I'm not so
> sure.
We can deprecate -mem-path and direct users to use explicitly
defined
On 17.08.23 17:31, Peter Xu wrote:
On Thu, Aug 17, 2023 at 05:15:52PM +0200, David Hildenbrand wrote:
I don't know how important that requirement was (that commit was a
request from Kata Containers).
Let me take a look if Kata passes "share=on,readonly=on" or
"share=off,readonly=off".
The
On Thu, Aug 17, 2023 at 05:15:52PM +0200, David Hildenbrand wrote:
> > I don't know how important that requirement was (that commit was a
> > request from Kata Containers).
>
> Let me take a look if Kata passes "share=on,readonly=on" or
> "share=off,readonly=off".
The question is whether it's
Commit 86635aa4e9d627d5142b81c57a33dd1f36627d07 mentions that we don't
want guests to be able to dirty pages on the host. The change you're
proposing would not protect against guests that dirty the memory.
The guest could write memory but not modify the file. Only with
On 17.08.23 17:13, Stefan Hajnoczi wrote:
On Thu, 17 Aug 2023 at 05:08, David Hildenbrand wrote:
@Stefan, see below on a R/O NVDIMM question.
We're discussing how to get MAPR_PRIVATE R/W mapping of a
memory-backend-file running when using R/O files.
This seems a good idea. I am good with
On Thu, 17 Aug 2023 at 05:08, David Hildenbrand wrote:
>
> @Stefan, see below on a R/O NVDIMM question.
>
> We're discussing how to get MAPR_PRIVATE R/W mapping of a
> memory-backend-file running when using R/O files.
>
> >
> > This seems a good idea. I am good with the solution you proposed
> >
On 17.08.23 16:41, Peter Xu wrote:
On Thu, Aug 17, 2023 at 11:07:23AM +0200, David Hildenbrand wrote:
@Stefan, see below on a R/O NVDIMM question.
We're discussing how to get MAPR_PRIVATE R/W mapping of a
memory-backend-file running when using R/O files.
This seems a good idea. I am good
On 17.08.23 16:45, Daniel P. Berrangé wrote:
On Thu, Aug 17, 2023 at 04:37:52PM +0200, David Hildenbrand wrote:
On 17.08.23 16:37, Daniel P. Berrangé wrote:
On Thu, Aug 17, 2023 at 04:30:16PM +0200, David Hildenbrand wrote:
@Stefan, do you have any concern when we would do 1) ?
As far as I
On Thu, Aug 17, 2023 at 04:37:52PM +0200, David Hildenbrand wrote:
> On 17.08.23 16:37, Daniel P. Berrangé wrote:
> > On Thu, Aug 17, 2023 at 04:30:16PM +0200, David Hildenbrand wrote:
> > >
> > > > @Stefan, do you have any concern when we would do 1) ?
> > > >
> > > > As far as I can tell, we
On Thu, Aug 17, 2023 at 11:07:23AM +0200, David Hildenbrand wrote:
> @Stefan, see below on a R/O NVDIMM question.
>
> We're discussing how to get MAPR_PRIVATE R/W mapping of a
> memory-backend-file running when using R/O files.
>
> >
> > This seems a good idea. I am good with the solution you
On 17.08.23 16:37, Daniel P. Berrangé wrote:
On Thu, Aug 17, 2023 at 04:30:16PM +0200, David Hildenbrand wrote:
@Stefan, do you have any concern when we would do 1) ?
As far as I can tell, we have to set the nvdimm to "unarmed=on" either way:
+ "unarmed" controls the ACPI NFIT NVDIMM
On Thu, Aug 17, 2023 at 04:30:16PM +0200, David Hildenbrand wrote:
>
> > @Stefan, do you have any concern when we would do 1) ?
> >
> > As far as I can tell, we have to set the nvdimm to "unarmed=on" either way:
> >
> > + "unarmed" controls the ACPI NFIT NVDIMM Region Mapping Structure
@Stefan, do you have any concern when we would do 1) ?
As far as I can tell, we have to set the nvdimm to "unarmed=on" either way:
+ "unarmed" controls the ACPI NFIT NVDIMM Region Mapping Structure "NVDIMM
+ State Flags" Bit 3 indicating that the device is "unarmed" and cannot accept
+
On Fri, Aug 11, 2023 at 09:00:54PM +0200, David Hildenbrand wrote:
> On 11.08.23 07:49, ThinerLogoer wrote:
> > At 2023-08-11 05:24:43, "Peter Xu" wrote:
> > > On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
> > > > > I think we have the following options (there might be more)
> > >
On Thu, Aug 10, 2023 at 04:19:45PM +0200, David Hildenbrand wrote:
> > > Most importantly, we won't be corrupting/touching the original file in any
> > > case, because it is R/O.
> > >
> > > If we really want to be careful, we could clue that behavior to compat
> > > machines. I'm not really sure
On 17.08.23 15:46, Daniel P. Berrangé wrote:
On Fri, Aug 11, 2023 at 09:00:54PM +0200, David Hildenbrand wrote:
On 11.08.23 07:49, ThinerLogoer wrote:
At 2023-08-11 05:24:43, "Peter Xu" wrote:
On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
I think we have the following
On Mon, Aug 07, 2023 at 09:07:32PM +0200, David Hildenbrand wrote:
> From: Thiner Logoer
>
> Users may specify
> * "-mem-path" or
> * "-object memory-backend-file,share=off,readonly=off"
> and expect such COW (MAP_PRIVATE) mappings to work, even if the user
> does not have write permissions to
On 17.08.23 15:37, Daniel P. Berrangé wrote:
On Mon, Aug 07, 2023 at 09:07:32PM +0200, David Hildenbrand wrote:
From: Thiner Logoer
Users may specify
* "-mem-path" or
* "-object memory-backend-file,share=off,readonly=off"
and expect such COW (MAP_PRIVATE) mappings to work, even if the user
On 17.08.23 15:42, Daniel P. Berrangé wrote:
On Thu, Aug 10, 2023 at 04:19:45PM +0200, David Hildenbrand wrote:
Most importantly, we won't be corrupting/touching the original file in any
case, because it is R/O.
If we really want to be careful, we could clue that behavior to compat
machines.
@Stefan, see below on a R/O NVDIMM question.
We're discussing how to get MAPR_PRIVATE R/W mapping of a
memory-backend-file running when using R/O files.
This seems a good idea. I am good with the solution you proposed
here as well.
I was just going to get started working on that, when I
At 2023-08-11 22:31:36, "Peter Xu" wrote:
>On Fri, Aug 11, 2023 at 01:49:52PM +0800, ThinerLogoer wrote:
>> At 2023-08-11 05:24:43, "Peter Xu" wrote:
>> >On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
>> >> >I think we have the following options (there might be more)
>> >> >
>> >>
On Fri, Aug 11, 2023 at 07:39:37PM +0200, David Hildenbrand wrote:
> On 11.08.23 18:54, Peter Xu wrote:
> > On Fri, Aug 11, 2023 at 06:25:14PM +0200, David Hildenbrand wrote:
> > > On 11.08.23 18:22, Peter Xu wrote:
> > > > On Fri, Aug 11, 2023 at 06:17:05PM +0200, David Hildenbrand wrote:
> > > >
On 11.08.23 07:49, ThinerLogoer wrote:
At 2023-08-11 05:24:43, "Peter Xu" wrote:
On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
I think we have the following options (there might be more)
1) This patch.
2) New flag for memory-backend-file. We already have "readonly" and
On 11.08.23 18:54, Peter Xu wrote:
On Fri, Aug 11, 2023 at 06:25:14PM +0200, David Hildenbrand wrote:
On 11.08.23 18:22, Peter Xu wrote:
On Fri, Aug 11, 2023 at 06:17:05PM +0200, David Hildenbrand wrote:
We wouldn't touch "-mem-path".
But still the same issue when someone uses -object
On Fri, Aug 11, 2023 at 06:25:14PM +0200, David Hildenbrand wrote:
> On 11.08.23 18:22, Peter Xu wrote:
> > On Fri, Aug 11, 2023 at 06:17:05PM +0200, David Hildenbrand wrote:
> > > We wouldn't touch "-mem-path".
> >
> > But still the same issue when someone uses -object memory-backend-file for
>
On 11.08.23 18:22, Peter Xu wrote:
On Fri, Aug 11, 2023 at 06:17:05PM +0200, David Hildenbrand wrote:
We wouldn't touch "-mem-path".
But still the same issue when someone uses -object memory-backend-file for
hugetlb, mapping privately, expecting ram discard to work?
Basically I see that
On Fri, Aug 11, 2023 at 06:17:05PM +0200, David Hildenbrand wrote:
> We wouldn't touch "-mem-path".
But still the same issue when someone uses -object memory-backend-file for
hugetlb, mapping privately, expecting ram discard to work?
Basically I see that example as, "hugetlb" in general made the
On 11.08.23 18:16, Peter Xu wrote:
On Fri, Aug 11, 2023 at 05:26:24PM +0200, David Hildenbrand wrote:
I just started looking into the origins of "-mem-path".
Originally c902760fb2 ("Add option to use file backed guest memory"):
* Without MAP_POPULATE support, we use MAP_PRIVATE
* With
On Fri, Aug 11, 2023 at 05:26:24PM +0200, David Hildenbrand wrote:
> I just started looking into the origins of "-mem-path".
>
> Originally c902760fb2 ("Add option to use file backed guest memory"):
>
> * Without MAP_POPULATE support, we use MAP_PRIVATE
> * With MAP_POPULATE support we use
On Fri, Aug 11, 2023 at 04:59:56PM +0200, David Hildenbrand wrote:
> On 10.08.23 23:24, Peter Xu wrote:
> > On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
> > > > I think we have the following options (there might be more)
> > > >
> > > > 1) This patch.
> > > >
> > > > 2) New flag
On 11.08.23 16:59, David Hildenbrand wrote:
On 10.08.23 23:24, Peter Xu wrote:
On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
I think we have the following options (there might be more)
1) This patch.
2) New flag for memory-backend-file. We already have "readonly" and
On 10.08.23 23:24, Peter Xu wrote:
On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
I think we have the following options (there might be more)
1) This patch.
2) New flag for memory-backend-file. We already have "readonly" and
"share=". I'm having a hard time coming up with a
On Fri, Aug 11, 2023 at 01:49:52PM +0800, ThinerLogoer wrote:
> At 2023-08-11 05:24:43, "Peter Xu" wrote:
> >On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
> >> >I think we have the following options (there might be more)
> >> >
> >> >1) This patch.
> >> >
> >> >2) New flag for
At 2023-08-11 05:24:43, "Peter Xu" wrote:
>On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
>> >I think we have the following options (there might be more)
>> >
>> >1) This patch.
>> >
>> >2) New flag for memory-backend-file. We already have "readonly" and
>> >"share=". I'm having a
On Fri, Aug 11, 2023 at 01:06:12AM +0800, ThinerLogoer wrote:
> >I think we have the following options (there might be more)
> >
> >1) This patch.
> >
> >2) New flag for memory-backend-file. We already have "readonly" and
> >"share=". I'm having a hard time coming up with a good name that really
Most importantly, we won't be corrupting/touching the original file in any
case, because it is R/O.
If we really want to be careful, we could clue that behavior to compat
machines. I'm not really sure yet if we really have to go down that path.
Any other alternatives? I'd like to avoid new
On Wed, Aug 09, 2023 at 11:20:11AM +0200, David Hildenbrand wrote:
> Hi Peter!
Hi, David,
>
> > > -fd = file_ram_open(mem_path, memory_region_name(mr), readonly,
> > > ,
> > > - errp);
> > > +fd = file_ram_open(mem_path, memory_region_name(mr), readonly,
> > > );
Hi Peter!
-fd = file_ram_open(mem_path, memory_region_name(mr), readonly, ,
- errp);
+fd = file_ram_open(mem_path, memory_region_name(mr), readonly, );
+if (fd == -EACCES && !(ram_flags & RAM_SHARED) && !readonly) {
+/*
+ * We can have a
On Mon, Aug 07, 2023 at 09:07:32PM +0200, David Hildenbrand wrote:
> From: Thiner Logoer
>
> Users may specify
> * "-mem-path" or
> * "-object memory-backend-file,share=off,readonly=off"
> and expect such COW (MAP_PRIVATE) mappings to work, even if the user
> does not have write permissions to
40 matches
Mail list logo
