On 31/01/19 14:03, Raslan, KarimAllah wrote:
>
> One option here would be to add 'e820__mapped_raw_any' (or whatever
> other name) and make it identical to the current implementation of
> e820__mapped_any at. Would that be slightly more acceptable? :)
Yes, of course it would (for me at least
On Wed, 2019-01-30 at 18:14 +0100, Paolo Bonzini wrote:
> On 25/01/19 19:28, Raslan, KarimAllah wrote:
> >
> > So the simple way to do it is:
> >
> > 1- Pass 'mem=' in the kernel command-line to limit the amount of memory
> > managed
> > by the kernel.
> > 2- Map this physical memory you
On 25/01/19 19:28, Raslan, KarimAllah wrote:
> So the simple way to do it is:
>
> 1- Pass 'mem=' in the kernel command-line to limit the amount of memory
> managed
> by the kernel.
> 2- Map this physical memory you want to give to the guest with
> mmap("/dev/mem",
On Wed, 2019-01-23 at 13:16 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 09, 2019 at 10:42:00AM +0100, KarimAllah Ahmed wrote:
> >
> > Guest memory can either be directly managed by the kernel (i.e. have a
> > "struct
> > page") or they can simply live outside kernel control (i.e. do not
On Wed, Jan 09, 2019 at 10:42:00AM +0100, KarimAllah Ahmed wrote:
> Guest memory can either be directly managed by the kernel (i.e. have a "struct
> page") or they can simply live outside kernel control (i.e. do not have a
> "struct page"). KVM mostly support these two modes, except in a few
Guest memory can either be directly managed by the kernel (i.e. have a "struct
page") or they can simply live outside kernel control (i.e. do not have a
"struct page"). KVM mostly support these two modes, except in a few places
where the code seems to assume that guest memory must have a "struct
6 matches
Mail list logo
