On 01/09/2012 05:28 PM, Jan Kiszka wrote:
> On 2012-01-09 16:25, Stefano Stabellini wrote:
> > On Sun, 8 Jan 2012, Avi Kivity wrote:
> >> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> >>> Avi, if you think that early_savevm is a decent solution, we'll start
> >>> working on it.
> >>
> >> I d
On 2012-01-09 16:25, Stefano Stabellini wrote:
> On Sun, 8 Jan 2012, Avi Kivity wrote:
>> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
>>> Avi, if you think that early_savevm is a decent solution, we'll start
>>> working on it.
>>
>> I don't like early_savevm because it complicates life for d
On Sun, 8 Jan 2012, Avi Kivity wrote:
> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> > Avi, if you think that early_savevm is a decent solution, we'll start
> > working on it.
>
> I don't like early_savevm because it complicates life for devices, for
> what is a localized problem. But if
On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> Avi, if you think that early_savevm is a decent solution, we'll start
> working on it.
I don't like early_savevm because it complicates life for devices, for
what is a localized problem. But if everything else is even more
complicated maybe we
On 2012-01-06 13:58, Peter Maydell wrote:
> On 6 January 2012 13:30, Jan Kiszka wrote:
>> The third point indicates that there is rather more generic room for
>> improvements: Why should qemu reset device models before restore at all?
>
> Commit 5a8a49d7aa says:
> # if we load from a snapshot, th
On 6 January 2012 13:30, Jan Kiszka wrote:
> The third point indicates that there is rather more generic room for
> improvements: Why should qemu reset device models before restore at all?
Commit 5a8a49d7aa says:
# if we load from a snapshot, the machine can be in any state. That can
# cause trou
On Fri, 6 Jan 2012, Jan Kiszka wrote:
> On 2012-01-06 08:50, Stefano Stabellini wrote:
> > On Thu, 5 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-05 15:50, Avi Kivity wrote:
> Let me summarize what we have come up with so far:
>
> - we move the call to xen_register_framebuffer before
On 2012-01-06 08:50, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-05 15:50, Avi Kivity wrote:
Let me summarize what we have come up with so far:
- we move the call to xen_register_framebuffer before
memory_region_init_ram in vga_common_init;
>>
On 01/06/2012 02:22 PM, Jan Kiszka wrote:
> >
> > Adding more concepts, just to work around a bug (and this is really a
> > bug in the qemu/xen interface) makes it harder to refactor things later on.
>
> Well, it's at least only a single concept, one that could even be used
> independently of Xen
On 2012-01-06 10:19, Avi Kivity wrote:
> On 01/05/2012 08:49 PM, Jan Kiszka wrote:
>> To me this still sounds like a cirrus-only xen workaround that
>> nevertheless spreads widely.
>
> It is.
>
>> Again, what speaks against migrating the information Xen needs before
>> creating the machine or a s
On 01/05/2012 08:49 PM, Jan Kiszka wrote:
> To me this still sounds like a cirrus-only xen workaround that
> nevertheless spreads widely.
It is.
> Again, what speaks against migrating the information Xen needs before
> creating the machine or a single device? That would only introduce a
> generic
On Thu, 5 Jan 2012, Jan Kiszka wrote:
> On 2012-01-05 15:50, Avi Kivity wrote:
> >> Let me summarize what we have come up with so far:
> >>
> >> - we move the call to xen_register_framebuffer before
> >> memory_region_init_ram in vga_common_init;
> >>
> >> - we prevent xen_ram_alloc from allocating
On 2012-01-05 15:50, Avi Kivity wrote:
>> Let me summarize what we have come up with so far:
>>
>> - we move the call to xen_register_framebuffer before
>> memory_region_init_ram in vga_common_init;
>>
>> - we prevent xen_ram_alloc from allocating a second framebuffer on
>> restore, checking for mr
On 01/05/2012 07:21 PM, Stefano Stabellini wrote:
> > > BTW what you are suggesting is not so different from what was done by
> > > Anthony in the last patch series he sent. See the following (ugly) patch
> > > to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> > > completed and
On Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 05:53 PM, Stefano Stabellini wrote:
> >
> > > This involves:
> > > - adding vmstate to xen-all.c so it can migrate the xen vram address
> >
> > Easy so far.
> >
> >
> > > - making sure the memory core doesn't do mappings during restore (can be
>
On 01/05/2012 05:53 PM, Stefano Stabellini wrote:
>
> > This involves:
> > - adding vmstate to xen-all.c so it can migrate the xen vram address
>
> Easy so far.
>
>
> > - making sure the memory core doesn't do mappings during restore (can be
> > done by wrapping restore with
> > memory_region_trans
On Thu, 5 Jan 2012, Avi Kivity wrote:
> > If the MemoryRegions are re-created by the devices, then we need another
> > mechanism to find out where the videoram is.
> > What I am saying is that the suggestion of having a xen_address field
> > for every MemoryRegion would make the code cleaner but it
On 01/05/2012 04:34 PM, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Avi Kivity wrote:
> > On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > > save/restore functions so that at restore time we can get to know a
On Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > save/restore functions so that at restore time we can get to know at
> > > > what address the videoram is mapped into the gue
On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > The "solution" I am proposing is introducing an early_savevm set of
> > > save/restore functions so that at restore time we can get to know at
> > > what address the videoram is mapped into the guest address space. Once we
> > > know the addre
On Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 02:30 PM, Stefano Stabellini wrote:
> > > >
> > > > I cannot see how this is going to fix the save/restore issue we are
> > > > trying to solve.
> > > > The problem, unfortunately very complex, is that at restore time the
> > > > videoram is alr
On 01/05/2012 02:30 PM, Stefano Stabellini wrote:
> > >
> > > I cannot see how this is going to fix the save/restore issue we are
> > > trying to solve.
> > > The problem, unfortunately very complex, is that at restore time the
> > > videoram is already allocated at the physical address it was mapp
On Wed, 4 Jan 2012, Avi Kivity wrote:
> On 01/04/2012 06:38 PM, Stefano Stabellini wrote:
> >
> > > I suggest doing the following:
> > >
> > > 1. keep cirrus code unchanged
> > > 2. when the framebuffer is first mapped into physical memory (as known
> > > by your CPUPhysMemoryClient), copy it into
On 01/04/2012 06:38 PM, Stefano Stabellini wrote:
>
> > I suggest doing the following:
> >
> > 1. keep cirrus code unchanged
> > 2. when the framebuffer is first mapped into physical memory (as known
> > by your CPUPhysMemoryClient), copy it into a temporary buffer, map the
> > guest memory into m
On Sun, 18 Dec 2011, Avi Kivity wrote:
> On 12/12/2011 05:32 PM, Stefano Stabellini wrote:
> > > Really, I think this is something inherently incompatible with the
> > > current memory API. If Xen has this unfixable special "requirement"
> > > (it's rather a design issue IMHO), adjust the API and a
On 12/12/2011 05:32 PM, Stefano Stabellini wrote:
> > Really, I think this is something inherently incompatible with the
> > current memory API. If Xen has this unfixable special "requirement"
> > (it's rather a design issue IMHO), adjust the API and adapt all devices.
> > Hot-fixing only a single
On Mon, 12 Dec 2011, Jan Kiszka wrote:
> Is there really no way to fix this properly in the Xen layer?
> >>>
> >>> We thought about this issue for some time but we couldn't come up with
> >>> anything better.
> >>> To summarize the problem:
> >>>
> >>> - on restore the videoram has already bee
On 2011-12-12 15:41, Stefano Stabellini wrote:
> On Mon, 12 Dec 2011, Jan Kiszka wrote:
>> On 2011-12-12 14:18, Stefano Stabellini wrote:
>>> On Sat, 10 Dec 2011, Jan Kiszka wrote:
On 2011-12-09 22:54, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the ac
On Mon, 12 Dec 2011, Jan Kiszka wrote:
> On 2011-12-12 14:18, Stefano Stabellini wrote:
> > On Sat, 10 Dec 2011, Jan Kiszka wrote:
> >> On 2011-12-09 22:54, Anthony PERARD wrote:
> >>> During the initialisation of the machine at restore time, the access to
> >>> the
> >>> VRAM will fail because QE
On 2011-12-12 14:18, Stefano Stabellini wrote:
> On Sat, 10 Dec 2011, Jan Kiszka wrote:
>> On 2011-12-09 22:54, Anthony PERARD wrote:
>>> During the initialisation of the machine at restore time, the access to the
>>> VRAM will fail because QEMU does not know yet the right guest address to
>>> map
On Sat, 10 Dec 2011, Jan Kiszka wrote:
> On 2011-12-09 22:54, Anthony PERARD wrote:
> > During the initialisation of the machine at restore time, the access to the
> > VRAM will fail because QEMU does not know yet the right guest address to
> > map,
> > so the vram_ptr is NULL.
> >
> > So this pa
On Fri, 9 Dec 2011, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to the
> VRAM will fail because QEMU does not know yet the right guest address to map,
> so the vram_ptr is NULL.
>
> So this patch avoid using a NULL pointer during initialisation, and
On 2011-12-09 22:54, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to the
> VRAM will fail because QEMU does not know yet the right guest address to map,
> so the vram_ptr is NULL.
>
> So this patch avoid using a NULL pointer during initialisation, an
During the initialisation of the machine at restore time, the access to the
VRAM will fail because QEMU does not know yet the right guest address to map,
so the vram_ptr is NULL.
So this patch avoid using a NULL pointer during initialisation, and try to get
another vram_ptr if the call failed the
34 matches
Mail list logo
