[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections |
Date: |
Mon, 20 Oct 2014 13:29:44 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 15.10.2014 um 09:55 hat Juan Quintela geschrieben:
> Hi
>
> by popular demand, and after too many time, this series. This is an
> RFC to know what people think about how to use them, the interface
> proposed, whatever.
> [...]
>
> Kevin: You asked for optional sections in the past for the block
> layer, would this proposal be enough for you?
I know I've asked in more than one occasion, and of course I don't
remember all the details any more. Anyway, I remember two cases offhand:
* qcow2 with patches like Delayed COW keeps internal block layer state
in memory that might need to be migrated. This series looks fine for
this case in principle, we'd just need to find a way to distinguish
the affected BlockDriverStates. We can probably take a node-name if it
exists (with Jeff's auto-naming patches not a problem, because then it
would always exist)
How do devices solve this? Do they use something like a qdev path to
identify to which device a given section belongs?
* When a VM is stopped after an I/O error, we need to migrate the
information about pending requests (bdrv_drain_all doesn't complete
the failed requests). Currently we do this in device code, but it
would be very nice to make this common block layer functionality.
The problem here is that bdrv_aio_readv/writev get an opaque pointer
back to the device, which of course becomes meaningless during
migration.
So this one is tricky even if we have optional top-level sections.
Kevin
- Re: [Qemu-devel] [PATCH 7/7] vmstate: Create optional sections, (continued)
- Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections,
Kevin Wolf <=