From: Kevin Wolf <kwolf@redhat.com>
To: Jason Baron <jbaron@redhat.com>
Cc: aliguori@us.ibm.com, jan.kiszka@siemens.com, agraf@suse.de,
qemu-devel@nongnu.org, yamahata@valinux.co.jp,
alex.williamson@redhat.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH] ahci: add migration support
Date: Fri, 31 Aug 2012 18:20:44 +0200 [thread overview]
Message-ID: <5040E45C.4090207@redhat.com> (raw)
In-Reply-To: <20120831154138.GD12212@redhat.com>
Am 31.08.2012 17:41, schrieb Jason Baron:
> On Fri, Aug 31, 2012 at 04:47:37PM +0200, Kevin Wolf wrote:
>> Am 30.08.2012 20:00, schrieb Jason Baron:
>>> Add support for ahci migration. This patch builds upon the patches posted
>>> previously by Andreas Faerber:
>>>
>>> http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01538.html
>>>
>>> (I hope I am giving Andreas proper credit for his work.)
>>>
>>> I've tested these patches by migrating Windows 7 and Fedora 16 guests on
>>> both piix with ahci attached and on q35 (which has a built-in ahci controller).
>>>
>>> Signed-off-by: Jason Baron <jbaron@redhat.com>
>>> ---
>>> hw/ide/ahci.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>>> hw/ide/ahci.h | 10 +++++++++
>>> hw/ide/ich.c | 11 +++++++--
>>> 3 files changed, 81 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
>>> index b53c757..e94509b 100644
>>> --- a/hw/ide/ahci.c
>>> +++ b/hw/ide/ahci.c
>>> @@ -1204,6 +1204,65 @@ void ahci_reset(AHCIState *s)
>>> }
>>> }
>>>
>>> +static const VMStateDescription vmstate_ahci_device = {
>>> + .name = "ahci port",
>>> + .version_id = 1,
>>> + .fields = (VMStateField []) {
>>> + VMSTATE_IDE_BUS(port, AHCIDevice),
>>> + VMSTATE_UINT32(port_state, AHCIDevice),
>>> + VMSTATE_UINT32(finished, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.lst_addr, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.lst_addr_hi, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.fis_addr, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.fis_addr_hi, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.irq_stat, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.irq_mask, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.cmd, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.tfdata, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.sig, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.scr_stat, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.scr_ctl, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.scr_err, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.scr_act, AHCIDevice),
>>> + VMSTATE_UINT32(port_regs.cmd_issue, AHCIDevice),
>>> + VMSTATE_END_OF_LIST()
>>> + },
>>> +};
>>
>> This looks incomplete to me. Everything below port_regs in AHCIDevice is
>> missing from the saved fields:
>>
>> struct AHCIDevice {
>> IDEDMA dma;
>> IDEBus port;
>> int port_no;
>> uint32_t port_state;
>> uint32_t finished;
>> AHCIPortRegs port_regs;
>> struct AHCIState *hba;
>
> set up in achi_init(), so I don't think we need this.
>
>> QEMUBH *check_bh;
>
> indicates if there is outstanding bh. Could cause a crash if there is an
> outstanding bh, and we don't have this field set. We could add a field
> to indicate if a bh is outstanding, cancel it in a pre_save, and then
> re-enable it during restore. Is i/o quiesced in any any way for
> migration? It also doesn't seem like other migration code paths are
> preserving the bh, for example, vmstate_bmdma, doesn't appear to save
> BMDMAState->bh?
Before sending the VM state, the migration code calls bdrv_drain_all(),
so we can be sure that no requests are in flight any more in the block
layer. There could still be requests pending in the AHCI or IDE code if
they aren't submitted instantly or just for resubmission after an I/O error.
>> int dma_status;
>> int done_atapi_packet;
>> int busy_slot;
>> int init_d2h_sent;
>
> These could easily be saved.
dma_status looks completely unused, it is never read. Can probably
remove it from the struct.
>> BlockDriverCompletionFunc *dma_cb;
>
> Not sure we even need this field in ahci?
Looks unused indeed.
>> Hm... Could we possibly test migration with qtest? I can imagine some
>> nice test cases there. It would require some new infrastructure, I
>> guess, but it could be doable.
>>
>
> That would be nice to shake out any bugs here.
Can you give it a try?
Kevin
next prev parent reply other threads:[~2012-08-31 16:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 18:00 [Qemu-devel] [PATCH] ahci: add migration support Jason Baron
2012-08-31 12:02 ` Alexandre DERUMIER
2012-08-31 14:47 ` Kevin Wolf
2012-08-31 15:41 ` Jason Baron
2012-08-31 16:20 ` Kevin Wolf [this message]
2012-08-31 15:55 ` Andreas Färber
2012-08-31 17:15 ` Jason Baron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5040E45C.4090207@redhat.com \
--to=kwolf@redhat.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=jbaron@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yamahata@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).