Re: [Qemu-devel] The first function called after migration for a block device
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
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 pbonz...@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
Re: [Qemu-devel] The first function called after migration for a block device
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
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 pbonz...@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
Re: [Qemu-devel] The first function called after migration for a block device
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
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 pbonz...@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
Re: [Qemu-devel] The first function called after migration for a block device
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
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 pbonz...@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
