On Tue, Jul 17, Olaf Hering wrote:
To make this robust against allocation errors I will change it to
do {
> + /* Allocate new mfn for previous pfn */
> + rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
} while (rc == 0);
> +
> + /* Make sure the prev
On Mon, Jul 16, Konrad Rzeszutek Wilk wrote:
> On Sun, Jul 15, 2012 at 06:06:53PM +0200, Olaf Hering wrote:
> > -void __ref xen_hvm_init_shared_info(void)
> > +static struct shared_info *hvm_shared_info;
> > +static unsigned long hvm_shared_info_pfn;
> > +
>
> Please include a big comment explain
On Sun, Jul 15, 2012 at 06:06:53PM +0200, Olaf Hering wrote:
> On Tue, Jul 10, Keir Fraser wrote:
>
> > Best thing to do, is possible, is map the shared-info page in the
> > xen-platform pci device's BAR memory range. Then it will not conflict with
> > any RAM.
>
> This patch does that. I did a k
On 15/07/2012 17:06, "Olaf Hering" wrote:
> On Tue, Jul 10, Keir Fraser wrote:
>
>> Best thing to do, is possible, is map the shared-info page in the
>> xen-platform pci device's BAR memory range. Then it will not conflict with
>> any RAM.
>
> This patch does that. I did a kexec boot and a save
On Tue, Jul 10, Keir Fraser wrote:
> Best thing to do, is possible, is map the shared-info page in the
> xen-platform pci device's BAR memory range. Then it will not conflict with
> any RAM.
This patch does that. I did a kexec boot and a save/restore.
It does not deal with the possible race were
On 13/07/2012 21:20, "Olaf Hering" wrote:
> On Tue, Jul 10, Keir Fraser wrote:
>
>> On 10/07/2012 19:09, "Olaf Hering" wrote:
>>> I'm not sure, most likely the gfn will just disappear from the guest,
>>> like a ballooned page disappears. Accessing it will likely cause a
>>> crash.
>>
>> Best t
On Tue, Jul 10, Keir Fraser wrote:
> On 10/07/2012 19:09, "Olaf Hering" wrote:
> > I'm not sure, most likely the gfn will just disappear from the guest,
> > like a ballooned page disappears. Accessing it will likely cause a
> > crash.
>
> Best thing to do, is possible, is map the shared-info pag
On 10/07/2012 19:09, "Olaf Hering" wrote:
>>> Are there more shared areas or is it just the shared info page?
>>>
And I am kind of worried that moving it to the .data section won't
be completly safe - as the decompressor might blow away that part too.
>>>
>>> The decompressor may just
On Tue, Jul 10, 2012 at 08:09:53PM +0200, Olaf Hering wrote:
> On Tue, Jul 10, Konrad Rzeszutek Wilk wrote:
>
> > On Tue, Jul 10, 2012 at 05:23:08PM +0200, Olaf Hering wrote:
> > > I was not thinking of statically allocated pages but some new concept of
> > > allocating such shared pages. Shouldnt
On Tue, Jul 10, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 10, 2012 at 05:23:08PM +0200, Olaf Hering wrote:
> > I was not thinking of statically allocated pages but some new concept of
> > allocating such shared pages. Shouldnt there be some dedicated area in
> > the E820 table which has to be use
On Tue, Jul 10, 2012 at 05:23:08PM +0200, Olaf Hering wrote:
> On Tue, Jul 10, Konrad Rzeszutek Wilk wrote:
>
> > On Tue, Jul 10, 2012 at 11:33:27AM +0200, Olaf Hering wrote:
> > > On Fri, Jul 06, Olaf Hering wrote:
> > >
> > > > On Fri, Jul 06, Jan Beulich wrote:
> > > >
> > > > > > Could it be
On Tue, Jul 10, Ian Campbell wrote:
> On Tue, 2012-07-10 at 10:51 -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 10, 2012 at 08:46:34AM -0600, Ian Campbell wrote:
> > > On Tue, 2012-07-10 at 10:14 -0400, Konrad Rzeszutek Wilk wrote:
> > > > Which brings me to another question - say we do use
On Tue, 2012-07-10 at 10:51 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 10, 2012 at 08:46:34AM -0600, Ian Campbell wrote:
> > On Tue, 2012-07-10 at 10:14 -0400, Konrad Rzeszutek Wilk wrote:
> > > Which brings me to another question - say we do use this patch, what
> > > if the decompressor ov
On Tue, Jul 10, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 10, 2012 at 11:33:27AM +0200, Olaf Hering wrote:
> > On Fri, Jul 06, Olaf Hering wrote:
> >
> > > On Fri, Jul 06, Jan Beulich wrote:
> > >
> > > > > Could it be that some code tweaks the stack content used by
> > > > > decompress()
> >
On Tue, Jul 10, 2012 at 08:46:34AM -0600, Ian Campbell wrote:
> On Tue, 2012-07-10 at 10:14 -0400, Konrad Rzeszutek Wilk wrote:
> > Which brings me to another question - say we do use this patch, what
> > if the decompressor overwrites the old kernels .data section. Won't
> > we run into this probl
On Tue, 2012-07-10 at 10:14 -0400, Konrad Rzeszutek Wilk wrote:
> Which brings me to another question - say we do use this patch, what
> if the decompressor overwrites the old kernels .data section. Won't
> we run into this problem again?
I've not really been following this thread that closely but
On Tue, Jul 10, 2012 at 11:33:27AM +0200, Olaf Hering wrote:
> On Fri, Jul 06, Olaf Hering wrote:
>
> > On Fri, Jul 06, Jan Beulich wrote:
> >
> > > > Could it be that some code tweaks the stack content used by decompress()
> > > > in some odd way? But that would most likely lead to a crash, not
On Fri, Jul 06, Olaf Hering wrote:
> On Fri, Jul 06, Jan Beulich wrote:
>
> > > Could it be that some code tweaks the stack content used by decompress()
> > > in some odd way? But that would most likely lead to a crash, not to
> > > unexpected uncompressing results.
> >
> > Especially if the old
On Fri, Jul 06, Jan Beulich wrote:
> > Could it be that some code tweaks the stack content used by decompress()
> > in some odd way? But that would most likely lead to a crash, not to
> > unexpected uncompressing results.
>
> Especially if the old and new kernel are using the exact same
> image,
19 matches
Mail list logo
