[Qemu-devel] The first function called after migration for a block device

[Qemu-devel] The first function called after migration for a block device

[Xiongzi Ge]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Hello,

When I studied the code, I found in migration.c,
bdrv_clear_incoming_migration_all();

the cache of the bdrv devices will be deleted.

Is this the one for the functions to be called after migration?

Does the bdrv device need to be reopen or load state in block.c?

I would like to find this function to add my new code.

Thanks.

[-- Attachment #2: Type: text/html, Size: 601 bytes --]

Re: [Qemu-devel] The first function called after migration for a block device

[Paolo Bonzini]

Il 27/06/2014 21:41, Xiongzi Ge ha scritto:
>
> When I studied the code, I found in migration.c,
> bdrv_clear_incoming_migration_all();
>
> the cache of the bdrv devices will be deleted.
>
> Is this the one for the functions to be called after migration?
>
> Does the bdrv device need to be reopen or load state in block.c?
>
> I would like to find this function to add my new code.

This function is not going to do anything if your code is in "raw" 
format.  In particular, it has *nothing* to do with the guest OS's 
cache.  That cache is managed by the guest OS and, as I have already 
told you multiple times, there is *nothing* that QEMU can do about it.

All you can do is use O_DIRECT in the guest.

Paolo

Re: [Qemu-devel] The first function called after migration for a block device

[Xiongzi Ge]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

Hi Paolo,

Thanks. I found a function called bdrv_invalidate_cache() in qcow2.c. After
migration, it will be called to invalidate the cache of the block device?


On Fri, Jun 27, 2014 at 5:49 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 27/06/2014 21:41, Xiongzi Ge ha scritto:
>
>
>> When I studied the code, I found in migration.c,
>> bdrv_clear_incoming_migration_all();
>>
>> the cache of the bdrv devices will be deleted.
>>
>> Is this the one for the functions to be called after migration?
>>
>> Does the bdrv device need to be reopen or load state in block.c?
>>
>> I would like to find this function to add my new code.
>>
>
> This function is not going to do anything if your code is in "raw" format.
>  In particular, it has *nothing* to do with the guest OS's cache.  That
> cache is managed by the guest OS and, as I have already told you multiple
> times, there is *nothing* that QEMU can do about it.
>
> All you can do is use O_DIRECT in the guest.
>
> Paolo
>

[-- Attachment #2: Type: text/html, Size: 1591 bytes --]

Re: [Qemu-devel] The first function called after migration for a block device

[Paolo Bonzini]

Il 28/06/2014 00:54, Xiongzi Ge ha scritto:
> Hi Paolo,
>
> Thanks. I found a function called bdrv_invalidate_cache() in qcow2.c.
> After migration, it will be called to invalidate the cache of the block
> device?

Let me quote again:

>>     This function has *nothing* to do with the guest OS's
>>     cache.  That cache is managed by the guest OS and, as I have already
>>     told you multiple times, there is *nothing* that QEMU can do about it.
>>
>>     All you can do is use O_DIRECT in the guest.

Did you even *try* to understand this?!?

Paolo

Re: [Qemu-devel] The first function called after migration for a block device

[Xiongzi Ge]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

I tried. It invalidated the cache of the block device after migration. So,
here, we can use a new cache for the block device after migration. Is it
right?  I can implement a simple block driver in block/ directory.


On Mon, Jun 30, 2014 at 6:48 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 28/06/2014 00:54, Xiongzi Ge ha scritto:
>
>  Hi Paolo,
>>
>> Thanks. I found a function called bdrv_invalidate_cache() in qcow2.c.
>> After migration, it will be called to invalidate the cache of the block
>> device?
>>
>
> Let me quote again:
>
>      This function has *nothing* to do with the guest OS's
>>>
>>>     cache.  That cache is managed by the guest OS and, as I have already
>>>     told you multiple times, there is *nothing* that QEMU can do about
>>> it.
>>>
>>>     All you can do is use O_DIRECT in the guest.
>>>
>>
> Did you even *try* to understand this?!?
>
> Paolo
>
>

[-- Attachment #2: Type: text/html, Size: 1692 bytes --]

Re: [Qemu-devel] The first function called after migration for a block device

[Paolo Bonzini]

Il 30/06/2014 16:03, Xiongzi Ge ha scritto:
> I tried. It invalidated the cache of the block device after migration.

It didn't invalidate anything in the guest, and there's *NO WAY* 
absolutely for QEMU to influence the cache in the guest.

Again: all you can do is use O_DIRECT in the guest.

> So, here, we can use a new cache for the block device after migration.

I don't understand what you mean.

> Is it right?  I can implement a simple block driver in block/ directory.

Probably not.

Paolo

Re: [Qemu-devel] The first function called after migration for a block device

[Xiongzi Ge]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Hi,
I mean this function will be called after migration to do something for the
block device. I tried and debugged the qemu code. (like you have a qcow2
format device. This function will be called. We can put anything we want
here. We can reopen a new device.  We have a new format block device which
has a cache created by myself. I can modify and control the cache after
migration. Do you have any suggestions? Thanks. )


On Mon, Jun 30, 2014 at 10:35 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 30/06/2014 16:03, Xiongzi Ge ha scritto:
>
>  I tried. It invalidated the cache of the block device after migration.
>>
>
> It didn't invalidate anything in the guest, and there's *NO WAY*
> absolutely for QEMU to influence the cache in the guest.
>
> Again: all you can do is use O_DIRECT in the guest.
>
>
>  So, here, we can use a new cache for the block device after migration.
>>
>
> I don't understand what you mean.
>
>
>  Is it right?  I can implement a simple block driver in block/ directory.
>>
>
> Probably not.
>
> Paolo
>

[-- Attachment #2: Type: text/html, Size: 1874 bytes --]

Re: [Qemu-devel] The first function called after migration for a block device

[Paolo Bonzini]

Il 30/06/2014 16:47, Xiongzi Ge ha scritto:
> Hi,
> I mean this function will be called after migration to do something for
> the block device. I tried and debugged the qemu code. (like you have a
> qcow2 format device. This function will be called. We can put anything
> we want here. We can reopen a new device.  We have a new format block
> device which has a cache created by myself. I can modify and control the
> cache after migration. Do you have any suggestions? Thanks. )

As long as the cache is entirely in QEMU, yes.  This was not what your 
earlier messages implied.

Paolo

Re: [Qemu-devel] The first function called after migration for a block device

[Xiongzi Ge]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

Sorry for that. I planed to use the existing method in qemu to add some new
mechanism after migration.

Does qemu have a IPC channel to communicate during migration?


On Mon, Jun 30, 2014 at 11:13 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 30/06/2014 16:47, Xiongzi Ge ha scritto:
>
>  Hi,
>> I mean this function will be called after migration to do something for
>> the block device. I tried and debugged the qemu code. (like you have a
>> qcow2 format device. This function will be called. We can put anything
>> we want here. We can reopen a new device.  We have a new format block
>> device which has a cache created by myself. I can modify and control the
>> cache after migration. Do you have any suggestions? Thanks. )
>>
>
> As long as the cache is entirely in QEMU, yes.  This was not what your
> earlier messages implied.
>
> Paolo
>

[-- Attachment #2: Type: text/html, Size: 1400 bytes --]