[Qemu-devel] [PATCH] bios-tables-test: delete a assert about block name
From: Wei Yang <wei.y...@ucloud.cn>
The assert would be touched when the version of acpica is greater than or
equal to 20160318. its reason is that "Disasembler: Update a couple
output items(commit id: 1ecbb3d)" is introduced by Robert, the patch
emits the AML filename as a zero-length string, and allows the compiler
to create the name later.
Signed-off-by: Yang, Wei <wei.y...@ucloud.com>
CC: Michael S. Tsirkin <m...@redhat.com>
CC: Igor Mammedov <imamm...@redhat.com>
CC: qemu-devel@nongnu.org
---
tests/bios-tables-test.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 88dbf97853..d2ab073848 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -350,7 +350,6 @@ static GString *normalize_asl(gchar *asl_code)
/* strip def block name (it has file path in it) */
if (g_str_has_prefix(asl->str, DEF_BLOCK)) {
block_name = g_strstr_len(asl->str, asl->len, BLOCK_NAME_END);
-g_assert(block_name);
asl = g_string_erase(asl, 0,
block_name + sizeof(BLOCK_NAME_END) - asl->str);
}
--
2.11.0
Re: [Qemu-devel] [PATCH] bitmap: refine and move BITMAP_{FIRST/LAST}_WORD_MASK
On Thu, Sep 29, 2016 at 07:11:39PM +0300, Michael Tokarev wrote:
>05.03.2016 16:47, Wei Yang wrote:
>>According to linux kernel commit <89c1e79eb30> ("linux/bitmap.h: improve
>>BITMAP_{LAST,FIRST}_WORD_MASK"), these two macro could be improved.
>>
>>This patch takes this change and also move them all in header file.
>
>Applied to -trivial, thank you!
>
Thanks :-) Have a good day~
>/mjt
--
Wei Yang
Help you, Help me
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
On Thu, Mar 24, 2016 at 01:32:25AM +, Li, Liang Z wrote: >> >> >> > >> >> >> >6. Handling page cache in the guest The memory used for page >> >> >> >cache in the guest will change depends on the workload, if guest >> >> >> >run some block IO intensive work load, there will >> >> >> >> >> >> Would this improvement benefit a lot when guest only has little free >> page? >> >> > >> >> >Yes, the improvement is very obvious. >> >> > >> >> >> >> Good to know this. >> >> >> >> >> In your Performance data Case 2, I think it mimic this kind of case. >> >> >> While the memory consuming task is stopped before migration. If it >> >> >> continues, would we still perform better than before? >> >> > >> >> >Actually, my RFC patch didn't consider the page cache, Roman raised >> >> >this >> >> issue. >> >> >so I add this part in this doc. >> >> > >> >> >Case 2 didn't mimic this kind of scenario, the work load is an >> >> >memory consuming work load, not an block IO intensive work load, so >> >> >there are not many page cache in this case. >> >> > >> >> >If the work load in case 2 continues, as long as it not write all >> >> >the memory it allocates, we still can get benefits. >> >> > >> >> >> >> Sounds I have little knowledge on page cache, and its relationship >> >> between free page and I/O intensive work. >> >> >> >> Here is some personal understanding, I would appreciate if you could >> >> correct me. >> >> >> >> +-+ >> >> |PageCache| >> >> +-+ >> >> +-+-+-+-+ >> >> |Page |Page |Free Page|Page | >> >> +-+-+-+-+ >> >> >> >> Free Page is a page in the free_list, PageCache is some page cached >> >> in CPU's cache line? >> > >> >No, page cache is quite different with CPU cache line. >> >" In computing, a page cache, sometimes also called disk cache,[2] is a >> >transparent cache for the pages originating from a secondary storage >> device such as a hard disk drive (HDD). >> > The operating system keeps a page cache in otherwise unused portions >> >of the main memory (RAM), resulting in quicker access to the contents >> >of cached pages and overall performance improvements " >> >you can refer to https://en.wikipedia.org/wiki/Page_cache >> >for more details. >> > >> >> My poor knowledge~ Should google it before I imagine the meaning of the >> terminology. >> >> If my understanding is correct, the Page Cache is counted as Free Page, while >> actually we should migrate them instead of filter them. > >No, the Page Cache is not counted as Free Page ... OK, I misunderstand the concept in wiki. The Page Cache is a trade off between Free Page percentage and the I/O performance in guest. > >Liang -- Richard Yang\nHelp you, Help me
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
On Wed, Mar 23, 2016 at 06:48:22AM +, Li, Liang Z wrote:
[...]
>> > 8. Pseudo code
>> > Dirty page logging should be enabled before getting the free page
>> > information from guest, this is important because during the process
>> > of getting free pages, some free pages may be used and written by the
>> > guest, dirty page logging can trace these pages. The pseudo code is
>> > like below:
>> >
>> > ---
>> > MigrationState *s = migrate_get_current();
>> > ...
>> >
>> > memory_global_dirty_log_start();
>> >
>> > if (get_guest_mem_info()) {
>> > while (!get_free_page_bmap(free_page_bitmap, drop_page_cache)
>> &&
>> >s->state != MIGRATION_STATUS_CANCELLING) {
>> > usleep(1000) // sleep for 1 ms
>> > }
>> >
>> > tighten_free_page_bmap =
>> tighten_guest_free_pages(free_page_bitmap);
>> > filter_out_guest_free_pages(tighten_free_page_bmap);
>> > }
>>
>> Given the typical speed of networks; it wouldn't do too much harm to start
>> sending assuming all pages are dirty and then when the guest finally gets
>> around to finishing the bitmap then update, so it's asynchronous - and then
>> if
>> the guest never responds we don't really care.
>
>Indeed, thanks!
>
This is interesting. By doing so, the threshold I mentioned in another mail is
not necessary, since we can do it in parallel.
>Liang
>>
>> Dave
>>
>> >
>> > migration_bitmap_sync();
>> > ...
>> >
>> > ---
>> >
>> >
>> > --
>> > 1.9.1
>> >
>> --
>> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>N�r��y���b�X��ǧv�^�){.n�+h����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?&�)ߢf
--
Richard Yang\nHelp you, Help me
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
On Wed, Mar 23, 2016 at 02:35:42PM +, Li, Liang Z wrote: >> >No special purpose. Maybe it's caused by the email client. I didn't >> >find the character in the original doc. >> > >> >> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00715.html >> >> You could take a look at this link, there is a '>' before From. > >Yes, there is. > >> >> > >> >> >6. Handling page cache in the guest >> >> >The memory used for page cache in the guest will change depends on >> >> >the workload, if guest run some block IO intensive work load, there >> >> >will >> >> >> >> Would this improvement benefit a lot when guest only has little free page? >> > >> >Yes, the improvement is very obvious. >> > >> >> Good to know this. >> >> >> In your Performance data Case 2, I think it mimic this kind of case. >> >> While the memory consuming task is stopped before migration. If it >> >> continues, would we still perform better than before? >> > >> >Actually, my RFC patch didn't consider the page cache, Roman raised this >> issue. >> >so I add this part in this doc. >> > >> >Case 2 didn't mimic this kind of scenario, the work load is an memory >> >consuming work load, not an block IO intensive work load, so there are >> >not many page cache in this case. >> > >> >If the work load in case 2 continues, as long as it not write all the >> >memory it allocates, we still can get benefits. >> > >> >> Sounds I have little knowledge on page cache, and its relationship between >> free page and I/O intensive work. >> >> Here is some personal understanding, I would appreciate if you could correct >> me. >> >> +-+ >> |PageCache| >> +-+ >> +-+-+-+-+ >> |Page |Page |Free Page|Page | >> +-+-+-+-+ >> >> Free Page is a page in the free_list, PageCache is some page cached in CPU's >> cache line? > >No, page cache is quite different with CPU cache line. >" In computing, a page cache, sometimes also called disk cache,[2] is a >transparent cache > for the pages originating from a secondary storage device such as a hard disk > drive (HDD). > The operating system keeps a page cache in otherwise unused portions of the > main > memory (RAM), resulting in quicker access to the contents of cached pages and >overall performance improvements " >you can refer to https://en.wikipedia.org/wiki/Page_cache >for more details. > My poor knowledge~ Should google it before I imagine the meaning of the terminology. If my understanding is correct, the Page Cache is counted as Free Page, while actually we should migrate them instead of filter them. > >> When memory consuming task runs, it leads to little Free Page in the whole >> system. What's the consequence when I/O intensive work runs? I guess it >> still leads to little Free Page. And will have some problem in sync on >> PageCache? >> >> >> >> >> I am thinking is it possible to have a threshold or configurable >> >> threshold to utilize free page bitmap optimization? >> >> >> > >> >Could you elaborate your idea? How does it work? >> > >> >> Let's back to Case 2. We run a memory consuming task which will leads to >> little Free Page in the whole system. Which means from Qemu perspective, >> little of the dirty_memory is filtered by Free Page list. My original >> question is >> whether your solution benefits in this scenario. As you mentioned it works >> fine. So maybe this threshold is not necessary. >> >I didn't quite understand your question before. >The benefits we get depends on the count of free pages we can filter out. >This is always true. > >> My original idea is in Qemu we can calculate the percentage of the Free Page >> in the whole system. If it finds there is only little percentage of Free >> Page, >> then we don't need to bother to use this method. >> > >I got you. The threshold can be used for optimization, but the effect is very >limited. >If there are only a few of free pages, the process of constructing the free >page >bitmap is very quick. >But we can stop doing the following things, e.g. sending the free page bitmap >and doing >the bitmap operation, theoretically, that may help to save some time, maybe >several ms. > Ha, you got what I mean. >I think a VM has no free pages at all is very rare, in the worst case, there >are still several > MB of free pages. The proper threshold should be determined by comparing the > extra > time spends on processing the free page bitmap and the time spends on sending >the several MB of free pages though the network. If the formal is longer, we >can stop >using this method. So we should take the network bandwidth into consideration, >it's >too complicated and not worth to do. > Yes, after some thinking, it maybe not that easy and worth to do this optimization. >Thanks > >Liang >> Have a nice day~ >> >> >Liang >> > >> >> >> >> -- >> >> Richard Yang\nHelp you, Help me >>
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
On Wed, Mar 23, 2016 at 10:53:42AM -0600, Eric Blake wrote: >On 03/23/2016 01:18 AM, Li, Liang Z wrote: > >>>> >>>> >From guest's point of view, there are some pages currently not used by >>> >>> I see in your original RFC patch and your RFC doc, this line starts with a >>> character '>'. Not sure this one has a special purpose? >>> >> >> No special purpose. Maybe it's caused by the email client. I didn't find the >> character in the original doc. >> > >Yes, it's an artifact used by many mailers so that mailboxes don't get >confused by a bare "From" at the start of a line but in the middle >rather than the start of a message. > >It's possible to avoid the artifact by using quoted-printable and >escaping the 'F', and I'm honestly a bit surprised that git doesn't do >it automatically. > Oh, first time to notice this, interesting~ >-- >Eric Blake eblake redhat com+1-919-301-3266 >Libvirt virtualization library http://libvirt.org > -- Wei Yang Help you, Help me
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
On Wed, Mar 23, 2016 at 07:18:57AM +, Li, Liang Z wrote: >> Hi, Liang >> >> This is a very clear documentation of your work, I appreciated it a lot. >> Below >> are some of my personal opinion and question. >> > >Thanks for your comments! > >> On Tue, Mar 22, 2016 at 03:43:49PM +0800, Liang Li wrote: >> >I have sent the RFC version patch set for live migration optimization >> >by skipping processing the free pages in the ram bulk stage and >> >received a lot of comments. The related threads can be found at: >> > >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00715.html >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00714.html >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00717.html >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00716.html >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00718.html >> > >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00719.html >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00720.html >> >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00721.html >> > >> >> Actually there are two threads, Qemu thread and kernel thread. It would be >> more clear for audience, if you just list two first mail for these two thread >> respectively. >> > >Indeed, my original version has this kind of information, but I removed it. > >> >To make things easier, I wrote this doc about the possible designs >> >and my choices. Comments are welcome! >> > >> >Content >> >=== >> >1. Background >> >2. Why not use virtio-balloon >> >3. Virtio interface >> >4. Constructing free page bitmap >> >5. Tighten free page bitmap >> >6. Handling page cache in the guest >> >7. APIs for live migration >> >8. Pseudo code >> > >> >Details >> >=== >> >1. Background >> >As we know, in the ram bulk stage of live migration, current QEMU live >> >migration implementation mark the all guest's RAM pages as dirtied in >> >the ram bulk stage, all these pages will be checked for zero page >> >first, and the page content will be sent to the destination depends on >> >the checking result, that process consumes quite a lot of CPU cycles >> >and network bandwidth. >> > >> >>From guest's point of view, there are some pages currently not used by >> >> I see in your original RFC patch and your RFC doc, this line starts with a >> character '>'. Not sure this one has a special purpose? >> > >No special purpose. Maybe it's caused by the email client. I didn't find the >character in the original doc. > https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00715.html You could take a look at this link, there is a '>' before From. >> >the guest, guest doesn't care about the content in these pages. Free >> >pages are this kind of pages which are not used by guest. We can make >> >use of this fact and skip processing the free pages in the ram bulk >> >stage, it can save a lot CPU cycles and reduce the network traffic >> >while speed up the live migration process obviously. >> > >> >Usually, only the guest has the information of free pages. But it’s >> >possible to let the guest tell QEMU it’s free page information by some >> >mechanism. E.g. Through the virtio interface. Once QEMU get the free >> >page information, it can skip processing these free pages in the ram >> >bulk stage by clearing the corresponding bit of the migration bitmap. >> > >> >2. Why not use virtio-balloon >> >Actually, the virtio-balloon can do the similar thing by inflating the >> >balloon before live migration, but its performance is no good, for an >> >8GB idle guest just boots, it takes about 5.7 Sec to inflate the >> >balloon to 7GB, but it only takes 25ms to get a valid free page bitmap >> >from the guest. There are some of reasons for the bad performance of >> >vitio-balloon: >> >a. allocating pages (5%, 304ms) >> >b. sending PFNs to host (71%, 4194ms) >> >c. address translation and madvise() operation (24%, 1423ms) >> >Debugging shows the time spends on these operations are listed in the >> >brackets above. By changing the VIRTIO_BALLOON_ARRAY_PFNS_MAX to a >> >large value, such as 16384, the time spends on sending the PFNs can be >> >reduced to about 400ms, but it’s still too long. >> > >> >Obviously, the virtio-balloon mechanism has a bigger performance >> >impact to the guest than the way we are trying to implement. >> > >> >3. Virtio interface >> >There are three different ways of using the virtio interface to >> >send the free page information. >> >a. Extend the current virtio device >> >The virtio spec has already defined some virtio devices, and we can >> >extend one of these devices so as to use it to transport the free page >> >information. It requires modifying the virtio spec. >> > >> >b. Implement a new virtio device >> >Implementing a brand new virtio device to exchange information >> >between host and guest is another choice. It requires modifying the >> >virtio spec too. >> > >> >c. Make use of virtio-serial (Amit’s
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages
Hi, Liang This is a very clear documentation of your work, I appreciated it a lot. Below are some of my personal opinion and question. On Tue, Mar 22, 2016 at 03:43:49PM +0800, Liang Li wrote: >I have sent the RFC version patch set for live migration optimization >by skipping processing the free pages in the ram bulk stage and >received a lot of comments. The related threads can be found at: > >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00715.html >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00714.html >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00717.html >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00716.html >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00718.html > >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00719.html >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00720.html >https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg00721.html > Actually there are two threads, Qemu thread and kernel thread. It would be more clear for audience, if you just list two first mail for these two thread respectively. >To make things easier, I wrote this doc about the possible designs >and my choices. Comments are welcome! > >Content >=== >1. Background >2. Why not use virtio-balloon >3. Virtio interface >4. Constructing free page bitmap >5. Tighten free page bitmap >6. Handling page cache in the guest >7. APIs for live migration >8. Pseudo code > >Details >=== >1. Background >As we know, in the ram bulk stage of live migration, current QEMU live >migration implementation mark the all guest's RAM pages as dirtied in >the ram bulk stage, all these pages will be checked for zero page >first, and the page content will be sent to the destination depends on >the checking result, that process consumes quite a lot of CPU cycles >and network bandwidth. > >>From guest's point of view, there are some pages currently not used by I see in your original RFC patch and your RFC doc, this line starts with a character '>'. Not sure this one has a special purpose? >the guest, guest doesn't care about the content in these pages. Free >pages are this kind of pages which are not used by guest. We can make >use of this fact and skip processing the free pages in the ram bulk >stage, it can save a lot CPU cycles and reduce the network traffic >while speed up the live migration process obviously. > >Usually, only the guest has the information of free pages. But it’s >possible to let the guest tell QEMU it’s free page information by some >mechanism. E.g. Through the virtio interface. Once QEMU get the free >page information, it can skip processing these free pages in the ram >bulk stage by clearing the corresponding bit of the migration bitmap. > >2. Why not use virtio-balloon >Actually, the virtio-balloon can do the similar thing by inflating the >balloon before live migration, but its performance is no good, for an >8GB idle guest just boots, it takes about 5.7 Sec to inflate the >balloon to 7GB, but it only takes 25ms to get a valid free page bitmap >from the guest. There are some of reasons for the bad performance of >vitio-balloon: >a. allocating pages (5%, 304ms) >b. sending PFNs to host (71%, 4194ms) >c. address translation and madvise() operation (24%, 1423ms) >Debugging shows the time spends on these operations are listed in the >brackets above. By changing the VIRTIO_BALLOON_ARRAY_PFNS_MAX to a >large value, such as 16384, the time spends on sending the PFNs can be >reduced to about 400ms, but it’s still too long. > >Obviously, the virtio-balloon mechanism has a bigger performance >impact to the guest than the way we are trying to implement. > >3. Virtio interface >There are three different ways of using the virtio interface to >send the free page information. >a. Extend the current virtio device >The virtio spec has already defined some virtio devices, and we can >extend one of these devices so as to use it to transport the free page >information. It requires modifying the virtio spec. > >b. Implement a new virtio device >Implementing a brand new virtio device to exchange information >between host and guest is another choice. It requires modifying the >virtio spec too. > >c. Make use of virtio-serial (Amit’s suggestion, my choice) >It’s possible to make use the virtio-serial for communication between >host and guest, the benefit of this solution is no need to modify the >virtio spec. > >4. Construct free page bitmap >To minimize the space for saving free page information, it’s better to >use a bitmap to describe the free pages. There are two ways to >construct the free page bitmap. > >a. Construct free page bitmap when demand (My choice) >Guest can allocate memory for the free page bitmap only when it >receives the request from QEMU, and set the free page bitmap by >traversing the free page list. The advantage of this way is that it’s >quite simple and easy to implement. The disadvantage is that the >traversing
Re: [Qemu-devel] [PATCH] vfio/pci: replace 1 with PCI_CAP_LIST_NEXT to make code self-explain
On Wed, Mar 16, 2016 at 12:52:52PM +0100, Paolo Bonzini wrote:
>
>
>On 16/03/2016 12:27, Michael Tokarev wrote:
>>> > for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp;
>>> > - tmp = pdev->config[tmp + 1]) {
>>> > + tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT]) {
>>> > -next = pdev->config[pos + 1];
>>> > +next = pdev->config[pos + PCI_CAP_LIST_NEXT];
>> Hmm. I'm not sure the new version is better, to me "+1" reads
>> easier than the new symbolic constant variant.
>>
>> If it were something like pdev->config[PCI_CAP_LIST_NEXT], that'd be
>> nice, but not "pos + PCI_CAP_LIST_NEXT".
>>
>> But again, I'm not pci config space expert and don't understand
>> the basics :)
Thanks Michael for your comment. By using the macro, audience is more easy to
understand it tries to get the position of next capability.
>
>Each capability is a node of a linked list, and the position of the next
>capability is at offset 1 inside the capability (here it is at offset 1
>from the tmp or pos base). I think the patch is an improvement.
>
Thanks Paolo for your reply. :-)
>Paolo
--
Wei Yang
Help you, Help me
Re: [Qemu-devel] [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC
Hi, Tianyu, I am testing your V2 patch set in our environment, while facing two issues now. Have a workaround for the first one and hope you could share some light on the second one :-) 1. Mismatch for ram_block (Have a workaround) --- Below is the error message on the destination: qemu-system-x86_64: Length mismatch: : 0x3000 in != 0x4000: Invalid argument qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram' qemu-system-x86_64: load of migration failed: Invalid argument With the following command line on source and destination respectively: git/qemu/x86_64-softmmu/qemu-system-x86_64 --enable-kvm -m 4096 -smp 4 --nographic -drive file=/root/nfs/rhel.img,format=raw,cache=none -device vfio-sriov,host=:03:10.0 git/qemu/x86_64-softmmu/qemu-system-x86_64 --enable-kvm -m 4096 -smp 4 --nographic -drive file=/root/nfs/rhel.img,format=raw,cache=none -device vfio-sriov,host=:03:10.0 --incoming tcp:0: By some debugging, the reason for this error is the ram_block->idstr of pass-through MMIO region is not set. My workaround is to add vmstate_register_ram() in vfio_mmap_region() after memory_region_init_ram_ptr() returns. I think this is not a good solution, since the ram_block->idstr is coded with the VF's BDF. So I guess this will not work when the VF has different BDF from source to destination respectively. Maybe my test step is not correct? 2. Failed to migrate the MAC address --- By adding some code in VF's driver in destination guest, I found the MAC information has been migrated to destination in adapter->hw.mac. While this is "reset" by VF's driver, when ixgbevf_migration_task is invoked at the end of the migration process. Below is what I have printed: The ifconfig output from destination: eth8 Link encap:Ethernet HWaddr 52:54:00:81:39:F2 inet addr:9.31.210.106 Bcast:9.31.255.255 Mask:255.255.0.0 inet6 addr: fe80::5054:ff:fe81:39f2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:66 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21840 (21.3 KiB) TX bytes:920 (920.0 b) The log message I printed in destination's VF driver: ixgbevf: migration end -- ixgbevf: original mac:52:54:00:81:39:f2 ixgbevf: after reset mac:52:54:00:92:04:a3 ixgbevf: migration end == I didn't take a close look in the "reset" function, while seems it retrieves the mac from VF hardware. Hmm... is there some possible way to have the same mac on both source and destination? At last, I appreciated all your work and help, learned much from your side. On Tue, Nov 24, 2015 at 09:35:17PM +0800, Lan Tianyu wrote: >This patchset is to propose a solution of adding live migration >support for SRIOV NIC. > >During migration, Qemu needs to let VF driver in the VM to know >migration start and end. Qemu adds faked PCI migration capability >to help to sync status between two sides during migration. > >Qemu triggers VF's mailbox irq via sending MSIX msg when migration >status is changed. VF driver tells Qemu its mailbox vector index >via the new PCI capability. In some cases(NIC is suspended or closed), >VF mailbox irq is freed and VF driver can disable irq injecting via >new capability. > >VF driver will put down nic before migration and put up again on >the target machine. > >Lan Tianyu (10): > Qemu/VFIO: Create head file pci.h to share data struct. > Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition > Qemu/VFIO: Rework vfio_std_cap_max_size() function > Qemu/VFIO: Add vfio_find_free_cfg_reg() to find free PCI config space >regs > Qemu/VFIO: Expose PCI config space read/write and msix functions > Qemu/PCI: Add macros for faked PCI migration capability > Qemu: Add post_load_state() to run after restoring CPU state > Qemu: Add save_before_stop callback to run just before stopping VCPU >during migration > Qemu/VFIO: Add SRIOV VF migration support > Qemu/VFIO: Misc change for enable migration with VFIO > > hw/vfio/Makefile.objs | 2 +- > hw/vfio/pci.c | 196 +--- > hw/vfio/pci.h | 168 + > hw/vfio/sriov.c | 178 > include/hw/pci/pci_regs.h | 19 + > include/migration/vmstate.h | 5 ++ > include/sysemu/sysemu.h | 1 + > linux-headers/linux/vfio.h | 16 > migration/migration.c | 3 +- > migration/savevm.c | 28 +++ > 10 files changed, 459 insertions(+), 157 deletions(-) > create mode 100644 hw/vfio/pci.h > create mode 100644 hw/vfio/sriov.c > >-- >1.9.3 > >
Re: [Qemu-devel] [PATCH] kvm/irqchip: use bitmap utility for gsi tracking
On Mon, Mar 07, 2016 at 10:47:53AM +0100, Paolo Bonzini wrote:
>On 06/03/2016 02:57, Wei Yang wrote:
>> By using utilities in bitops and bitmap, this patch tries to make it more
>> friendly to audience. No functional change.
>>
>> Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
>> ---
>> kvm-all.c | 34 ++
>> 1 file changed, 10 insertions(+), 24 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index bd9e764..ed3f4a2 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -90,7 +90,7 @@ struct KVMState
>> #ifdef KVM_CAP_IRQ_ROUTING
>> struct kvm_irq_routing *irq_routes;
>> int nr_allocated_irq_routes;
>> -uint32_t *used_gsi_bitmap;
>> +unsigned long *used_gsi_bitmap;
>> unsigned int gsi_count;
>> QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE];
>> #endif
>> @@ -951,12 +951,12 @@ typedef struct KVMMSIRoute {
>>
>> static void set_gsi(KVMState *s, unsigned int gsi)
>> {
>> -s->used_gsi_bitmap[gsi / 32] |= 1U << (gsi % 32);
>> +set_bit(gsi, s->used_gsi_bitmap);
>> }
>>
>> static void clear_gsi(KVMState *s, unsigned int gsi)
>> {
>> -s->used_gsi_bitmap[gsi / 32] &= ~(1U << (gsi % 32));
>> +clear_bit(gsi, s->used_gsi_bitmap);
>> }
>>
>> void kvm_init_irq_routing(KVMState *s)
>> @@ -965,17 +965,9 @@ void kvm_init_irq_routing(KVMState *s)
>>
>> gsi_count = kvm_check_extension(s, KVM_CAP_IRQ_ROUTING) - 1;
>> if (gsi_count > 0) {
>> -unsigned int gsi_bits, i;
>> -
>> /* Round up so we can search ints using ffs */
>> -gsi_bits = ALIGN(gsi_count, 32);
>> -s->used_gsi_bitmap = g_malloc0(gsi_bits / 8);
>> +s->used_gsi_bitmap = bitmap_new(gsi_count);
>> s->gsi_count = gsi_count;
>> -
>> -/* Mark any over-allocated bits as already in use */
>> -for (i = gsi_count; i < gsi_bits; i++) {
>> -set_gsi(s, i);
>> -}
>> }
>>
>> s->irq_routes = g_malloc0(sizeof(*s->irq_routes));
>> @@ -1105,9 +1097,7 @@ static void kvm_flush_dynamic_msi_routes(KVMState *s)
>>
>> static int kvm_irqchip_get_virq(KVMState *s)
>> {
>> -uint32_t *word = s->used_gsi_bitmap;
>> -int max_words = ALIGN(s->gsi_count, 32) / 32;
>> -int i, zeroes;
>> +int next_virq;
>>
>> /*
>> * PIC and IOAPIC share the first 16 GSI numbers, thus the available
>> @@ -1120,16 +1110,12 @@ static int kvm_irqchip_get_virq(KVMState *s)
>> }
>>
>> /* Return the lowest unused GSI in the bitmap */
>> -for (i = 0; i < max_words; i++) {
>> -zeroes = ctz32(~word[i]);
>> -if (zeroes == 32) {
>> - continue;
>> -}
>> -
>> -return zeroes + i * 32;
>> +next_virq = find_first_zero_bit(s->used_gsi_bitmap, s->gsi_count);
>> +if (next_virq >= s->gsi_count) {
>> +return -ENOSPC;
>> +} else {
>> +return next_virq;
>> }
>> -return -ENOSPC;
>> -
>> }
>>
>> static KVMMSIRoute *kvm_lookup_msi_route(KVMState *s, MSIMessage msg)
>>
>
>Queued, thanks. I will send a pull request today.
>
Thanks, glad to contribute :-)
>Paolo
--
Wei Yang
Help you, Help me
[Qemu-devel] [PATCH] kvm/irqchip: use bitmap utility for gsi tracking
By using utilities in bitops and bitmap, this patch tries to make it more
friendly to audience. No functional change.
Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
---
kvm-all.c | 34 ++
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index bd9e764..ed3f4a2 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -90,7 +90,7 @@ struct KVMState
#ifdef KVM_CAP_IRQ_ROUTING
struct kvm_irq_routing *irq_routes;
int nr_allocated_irq_routes;
-uint32_t *used_gsi_bitmap;
+unsigned long *used_gsi_bitmap;
unsigned int gsi_count;
QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE];
#endif
@@ -951,12 +951,12 @@ typedef struct KVMMSIRoute {
static void set_gsi(KVMState *s, unsigned int gsi)
{
-s->used_gsi_bitmap[gsi / 32] |= 1U << (gsi % 32);
+set_bit(gsi, s->used_gsi_bitmap);
}
static void clear_gsi(KVMState *s, unsigned int gsi)
{
-s->used_gsi_bitmap[gsi / 32] &= ~(1U << (gsi % 32));
+clear_bit(gsi, s->used_gsi_bitmap);
}
void kvm_init_irq_routing(KVMState *s)
@@ -965,17 +965,9 @@ void kvm_init_irq_routing(KVMState *s)
gsi_count = kvm_check_extension(s, KVM_CAP_IRQ_ROUTING) - 1;
if (gsi_count > 0) {
-unsigned int gsi_bits, i;
-
/* Round up so we can search ints using ffs */
-gsi_bits = ALIGN(gsi_count, 32);
-s->used_gsi_bitmap = g_malloc0(gsi_bits / 8);
+s->used_gsi_bitmap = bitmap_new(gsi_count);
s->gsi_count = gsi_count;
-
-/* Mark any over-allocated bits as already in use */
-for (i = gsi_count; i < gsi_bits; i++) {
-set_gsi(s, i);
-}
}
s->irq_routes = g_malloc0(sizeof(*s->irq_routes));
@@ -1105,9 +1097,7 @@ static void kvm_flush_dynamic_msi_routes(KVMState *s)
static int kvm_irqchip_get_virq(KVMState *s)
{
-uint32_t *word = s->used_gsi_bitmap;
-int max_words = ALIGN(s->gsi_count, 32) / 32;
-int i, zeroes;
+int next_virq;
/*
* PIC and IOAPIC share the first 16 GSI numbers, thus the available
@@ -1120,16 +1110,12 @@ static int kvm_irqchip_get_virq(KVMState *s)
}
/* Return the lowest unused GSI in the bitmap */
-for (i = 0; i < max_words; i++) {
-zeroes = ctz32(~word[i]);
-if (zeroes == 32) {
-continue;
-}
-
-return zeroes + i * 32;
+next_virq = find_first_zero_bit(s->used_gsi_bitmap, s->gsi_count);
+if (next_virq >= s->gsi_count) {
+return -ENOSPC;
+} else {
+return next_virq;
}
-return -ENOSPC;
-
}
static KVMMSIRoute *kvm_lookup_msi_route(KVMState *s, MSIMessage msg)
--
2.5.0
[Qemu-devel] [PATCH] bitmap: refine and move BITMAP_{FIRST/LAST}_WORD_MASK
According to linux kernel commit <89c1e79eb30> ("linux/bitmap.h: improve
BITMAP_{LAST,FIRST}_WORD_MASK"), these two macro could be improved.
This patch takes this change and also move them all in header file.
Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
---
include/qemu/bitmap.h | 7 ++-
util/bitmap.c | 2 --
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/include/qemu/bitmap.h b/include/qemu/bitmap.h
index 0e33fa5..864982d 100644
--- a/include/qemu/bitmap.h
+++ b/include/qemu/bitmap.h
@@ -58,11 +58,8 @@
* find_next_bit(addr, nbits, bit) Position next set bit in *addr >= bit
*/
-#define BITMAP_LAST_WORD_MASK(nbits)\
-( \
-((nbits) % BITS_PER_LONG) ? \
-(1UL<<((nbits) % BITS_PER_LONG))-1 : ~0UL \
-)
+#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1)))
+#define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
#define DECLARE_BITMAP(name,bits) \
unsigned long name[BITS_TO_LONGS(bits)]
diff --git a/util/bitmap.c b/util/bitmap.c
index 40aadfb..43ed011 100644
--- a/util/bitmap.c
+++ b/util/bitmap.c
@@ -157,8 +157,6 @@ int slow_bitmap_andnot(unsigned long *dst, const unsigned
long *bitmap1,
return result != 0;
}
-#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) % BITS_PER_LONG))
-
void bitmap_set(unsigned long *map, long start, long nr)
{
unsigned long *p = map + BIT_WORD(start);
--
2.5.0
Re: [Qemu-devel] [PATCH 2/2] s390x/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries
On Wed, Feb 24, 2016 at 10:40:15AM +0100, Cornelia Huck wrote: >On Fri, 19 Feb 2016 15:18:11 +0000 >Wei Yang <richard.weiy...@gmail.com> wrote: > >> Even PCI_CAP_FLAGS has the same value as PCI_MSIX_FLAGS, the later one is >> the more proper on retrieving MSIX entries. >> >> This patch uses PCI_MSIX_FLAGS to retrieve the MSIX entries. >> >> Signed-off-by: Wei Yang <richard.weiy...@gmail.com> >> CC: Cornelia Huck <cornelia.h...@de.ibm.com> >> CC: Christian Borntraeger <borntrae...@de.ibm.com> >> --- >> hw/s390x/s390-pci-bus.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > >Thanks, applied to s390-next. Thanks :-) -- Wei Yang Help you, Help me
Re: [Qemu-devel] [PATCH 2/2] s390x/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries
On Tue, Feb 23, 2016 at 02:17:11PM +0800, Yi Min Zhao wrote: >于 Mon, 22 Feb 2016 14:15:07 +0100 >Christian Borntraeger <borntrae...@de.ibm.com> 写道: > >> On 02/19/2016 04:18 PM, Wei Yang wrote: >> > Even PCI_CAP_FLAGS has the same value as PCI_MSIX_FLAGS, the later one is >> > the more proper on retrieving MSIX entries. >> > >> > This patch uses PCI_MSIX_FLAGS to retrieve the MSIX entries. >> > >> > Signed-off-by: Wei Yang <richard.weiy...@gmail.com> >> > CC: Cornelia Huck <cornelia.h...@de.ibm.com> >> > CC: Christian Borntraeger <borntrae...@de.ibm.com> >> > --- >> > hw/s390x/s390-pci-bus.c |2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c >> > index 132588b..9d40039 100644 >> > --- a/hw/s390x/s390-pci-bus.c >> > +++ b/hw/s390x/s390-pci-bus.c >> > @@ -523,7 +523,7 @@ static int s390_pcihost_setup_msix(S390PCIBusDevice >> > *pbdev) >> > return 0; >> > } >> > >> > -ctrl = pci_host_config_read_common(pbdev->pdev, pos + PCI_CAP_FLAGS, >> > +ctrl = pci_host_config_read_common(pbdev->pdev, pos + PCI_MSIX_FLAGS, >> > pci_config_size(pbdev->pdev), sizeof(ctrl)); >> > table = pci_host_config_read_common(pbdev->pdev, pos + PCI_MSIX_TABLE, >> > pci_config_size(pbdev->pdev), sizeof(table)); >> > >> >> looks sane. >> Yi Min, can you ack/nack? >> >> > >It looks sane to me. A little change. Thanks Yi Min and Christian. So someone would pick it up? -- Wei Yang Help you, Help me
Re: [Qemu-devel] [PATCH] migration: reorder code to make it symmetric
Hi, Amit
Do you like this one?
On Thu, Feb 04, 2016 at 10:50:30PM +, Wei Yang wrote:
>In qemu_savevm_state_complete_precopy(), it iterates on each device to add
>a json object and transfer related status to destination, while the order
>of the last two steps could be refined.
>
>Current order:
>
>json_start_object()
> save_section_header()
> vmstate_save()
>json_end_object()
> save_section_footer()
>
>After the change:
>
>json_start_object()
> save_section_header()
> vmstate_save()
> save_section_footer()
>json_end_object()
>
>This patch reorder the code to to make it symmetric. No functional change.
>
>Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
>---
> migration/savevm.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/migration/savevm.c b/migration/savevm.c
>index b9caf59..42bfab4 100644
>--- a/migration/savevm.c
>+++ b/migration/savevm.c
>@@ -1088,12 +1088,11 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f,
>bool iterable_only)
> json_prop_int(vmdesc, "instance_id", se->instance_id);
>
> save_section_header(f, se, QEMU_VM_SECTION_FULL);
>-
> vmstate_save(f, se, vmdesc);
>-
>-json_end_object(vmdesc);
> trace_savevm_section_end(se->idstr, se->section_id, 0);
> save_section_footer(f, se);
>+
>+json_end_object(vmdesc);
> }
>
> if (!in_postcopy) {
>--
>1.7.9.5
--
Wei Yang
Help you, Help me
Re: [Qemu-devel] [PATCH 1/2] vfio/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries
On Fri, Feb 19, 2016 at 09:45:32AM -0700, Alex Williamson wrote:
>On Fri, 19 Feb 2016 15:18:10 +0000
>Wei Yang <richard.weiy...@gmail.com> wrote:
>
>> Even PCI_CAP_FLAGS has the same value as PCI_MSIX_FLAGS, the later one is
>> the more proper on retrieving MSIX entries.
>>
>> This patch uses PCI_MSIX_FLAGS to retrieve the MSIX entries.
>>
>> Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
>> ---
>> hw/vfio/pci.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index e66c47f..321423b 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -1210,7 +1210,7 @@ static int vfio_msix_early_setup(VFIOPCIDevice *vdev)
>> }
>>
>> if (pread(fd, , sizeof(ctrl),
>> - vdev->config_offset + pos + PCI_CAP_FLAGS) != sizeof(ctrl)) {
>> + vdev->config_offset + pos + PCI_MSIX_FLAGS) != sizeof(ctrl)) {
>> return -errno;
>> }
>>
>
>This is certainly trivial, I'll grab it for the respin of yesterday's
>pull request. Thanks,
Thanks Alex, have a nice weekend :-)
>
>Alex
--
Wei Yang
Help you, Help me
[Qemu-devel] [PATCH 2/2] s390x/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries
Even PCI_CAP_FLAGS has the same value as PCI_MSIX_FLAGS, the later one is the more proper on retrieving MSIX entries. This patch uses PCI_MSIX_FLAGS to retrieve the MSIX entries. Signed-off-by: Wei Yang <richard.weiy...@gmail.com> CC: Cornelia Huck <cornelia.h...@de.ibm.com> CC: Christian Borntraeger <borntrae...@de.ibm.com> --- hw/s390x/s390-pci-bus.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index 132588b..9d40039 100644 --- a/hw/s390x/s390-pci-bus.c +++ b/hw/s390x/s390-pci-bus.c @@ -523,7 +523,7 @@ static int s390_pcihost_setup_msix(S390PCIBusDevice *pbdev) return 0; } -ctrl = pci_host_config_read_common(pbdev->pdev, pos + PCI_CAP_FLAGS, +ctrl = pci_host_config_read_common(pbdev->pdev, pos + PCI_MSIX_FLAGS, pci_config_size(pbdev->pdev), sizeof(ctrl)); table = pci_host_config_read_common(pbdev->pdev, pos + PCI_MSIX_TABLE, pci_config_size(pbdev->pdev), sizeof(table)); -- 1.7.9.5
[Qemu-devel] [PATCH 1/2] vfio/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries
Even PCI_CAP_FLAGS has the same value as PCI_MSIX_FLAGS, the later one is
the more proper on retrieving MSIX entries.
This patch uses PCI_MSIX_FLAGS to retrieve the MSIX entries.
Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
---
hw/vfio/pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index e66c47f..321423b 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1210,7 +1210,7 @@ static int vfio_msix_early_setup(VFIOPCIDevice *vdev)
}
if (pread(fd, , sizeof(ctrl),
- vdev->config_offset + pos + PCI_CAP_FLAGS) != sizeof(ctrl)) {
+ vdev->config_offset + pos + PCI_MSIX_FLAGS) != sizeof(ctrl)) {
return -errno;
}
--
1.7.9.5
[Qemu-devel] [PATCH 0/2] use PCI_MSIX_FLAGS on retrieving the MSIX entries
These two patches replace the PCI_CAP_FLAGS with PCI_MSIX_FLAGS on retrieving the MSIX entries. The change is the same, while I put them in two patches for different author to review. Wei Yang (2): vfio/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries s390x/pci: use PCI_MSIX_FLAGS on retrieving the MSIX entries hw/s390x/s390-pci-bus.c |2 +- hw/vfio/pci.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.9.5
Re: [Qemu-devel] [PATCH] migration: reorder code to make it symmetric
Hello everyone,
Is this one correct?
On Thu, Feb 04, 2016 at 10:50:30PM +, Wei Yang wrote:
>In qemu_savevm_state_complete_precopy(), it iterates on each device to add
>a json object and transfer related status to destination, while the order
>of the last two steps could be refined.
>
>Current order:
>
>json_start_object()
> save_section_header()
> vmstate_save()
>json_end_object()
> save_section_footer()
>
>After the change:
>
>json_start_object()
> save_section_header()
> vmstate_save()
> save_section_footer()
>json_end_object()
>
>This patch reorder the code to to make it symmetric. No functional change.
>
>Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
>---
> migration/savevm.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/migration/savevm.c b/migration/savevm.c
>index b9caf59..42bfab4 100644
>--- a/migration/savevm.c
>+++ b/migration/savevm.c
>@@ -1088,12 +1088,11 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f,
>bool iterable_only)
> json_prop_int(vmdesc, "instance_id", se->instance_id);
>
> save_section_header(f, se, QEMU_VM_SECTION_FULL);
>-
> vmstate_save(f, se, vmdesc);
>-
>-json_end_object(vmdesc);
> trace_savevm_section_end(se->idstr, se->section_id, 0);
> save_section_footer(f, se);
>+
>+json_end_object(vmdesc);
> }
>
> if (!in_postcopy) {
>--
>1.7.9.5
--
Wei Yang
Help you, Help me
[Qemu-devel] [PATCH] vfio/pci: replace 1 with PCI_CAP_LIST_NEXT to make code self-explain
Use the macro PCI_CAP_LIST_NEXT instead of 1, so that the code would be
more self-explain.
This patch makes this change and also fixs one typo in comment.
Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
---
hw/vfio/pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 1fb868c..17d1462 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1472,7 +1472,7 @@ static uint8_t vfio_std_cap_max_size(PCIDevice *pdev,
uint8_t pos)
uint8_t tmp, next = 0xff;
for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp;
- tmp = pdev->config[tmp + 1]) {
+ tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT]) {
if (tmp > pos && tmp < next) {
next = tmp;
}
@@ -1661,7 +1661,7 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t
pos)
int ret;
cap_id = pdev->config[pos];
-next = pdev->config[pos + 1];
+next = pdev->config[pos + PCI_CAP_LIST_NEXT];
/*
* If it becomes important to configure capabilities to their actual
@@ -1675,7 +1675,7 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t
pos)
* pci_add_capability always inserts the new capability at the head
* of the chain. Therefore to end up with a chain that matches the
* physical device, we insert from the end by making this recursive.
- * This is also why we pre-caclulate size above as cached config space
+ * This is also why we pre-calculate size above as cached config space
* will be changed as we unwind the stack.
*/
if (next) {
@@ -1691,7 +1691,7 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t
pos)
}
/* Use emulated next pointer to allow dropping caps */
-pci_set_byte(vdev->emulated_config_bits + pos + 1, 0xff);
+pci_set_byte(vdev->emulated_config_bits + pos + PCI_CAP_LIST_NEXT, 0xff);
switch (cap_id) {
case PCI_CAP_ID_MSI:
--
2.5.0
[Qemu-devel] [PATCH] migration: reorder code to make it symmetric
In qemu_savevm_state_complete_precopy(), it iterates on each device to add
a json object and transfer related status to destination, while the order
of the last two steps could be refined.
Current order:
json_start_object()
save_section_header()
vmstate_save()
json_end_object()
save_section_footer()
After the change:
json_start_object()
save_section_header()
vmstate_save()
save_section_footer()
json_end_object()
This patch reorder the code to to make it symmetric. No functional change.
Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
---
migration/savevm.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/migration/savevm.c b/migration/savevm.c
index b9caf59..42bfab4 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1088,12 +1088,11 @@ void qemu_savevm_state_complete_precopy(QEMUFile *f,
bool iterable_only)
json_prop_int(vmdesc, "instance_id", se->instance_id);
save_section_header(f, se, QEMU_VM_SECTION_FULL);
-
vmstate_save(f, se, vmdesc);
-
-json_end_object(vmdesc);
trace_savevm_section_end(se->idstr, se->section_id, 0);
save_section_footer(f, se);
+
+json_end_object(vmdesc);
}
if (!in_postcopy) {
--
1.7.9.5
Re: [Qemu-devel] [PATCH 2/2] qmp-spec: fix index in doc
On Sat, Jan 30, 2016 at 12:46:58PM +0300, Michael Tokarev wrote: >24.01.2016 17:09, Wei Yang wrote: >> The index is duplicated. Just change it. > >It is indeed, with previous being 2.5 as well >and the next being 3. Applying to -trivial. > >Please the next time send to qemu-devel@ and Cc to -trivial. > Thanks, got the correct procedure. >Thanks! > >/mjt > >> Signed-off-by: Wei Yang <richard.weiy...@gmail.com> >> --- >> docs/qmp-spec.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/docs/qmp-spec.txt b/docs/qmp-spec.txt >> index 4fb10a5..8e4bc3d 100644 >> --- a/docs/qmp-spec.txt >> +++ b/docs/qmp-spec.txt >> @@ -180,7 +180,7 @@ Some events are rate-limited to at most one per second. >> If additional >> dropped, and the last one is delayed. "Similar" normally means same >> event type. See qmp-events.txt for details. >> >> -2.5 QGA Synchronization >> +2.6 QGA Synchronization >> --- >> >> When using QGA, an additional synchronization feature is built into >> -- Wei Yang Help you, Help me
Re: [Qemu-devel] [PATCH 1/2] rdma: remove check on time_spent when calculating mbs
On Sat, Jan 30, 2016 at 12:45:27PM +0300, Michael Tokarev wrote:
>24.01.2016 17:09, Wei Yang wrote:
>> Within the if statement, time_spent is assured to be non-zero.
>>
>> This patch just removes the check on time_spent when calculating mbs.
>
>The if statement is this one:
>
>if (current_time >= initial_time + BUFFER_DELAY) {
>
>Note that we use time_spent as a divisor to calculate
>bandwidth too.
>
>This is indeed a trivial patch, I'm applying it to -trivial,
>but please the next time post it to qemu-devel (the main
>mailinglist), and Cc qemu-trivial if it is trivial.
>
To Amit and Michael,
Yep, thanks. I thought these two are too trivial to post to qemu-devel :)
Will do this next time.
>Thanks!
>
>/mjt
>
>> Signed-off-by: Wei Yang <richard.weiy...@gmail.com>
>> ---
>> migration/migration.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/migration/migration.c b/migration/migration.c
>> index c842499..40b87f2 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -1677,8 +1677,8 @@ static void *migration_thread(void *opaque)
>> double bandwidth = (double)transferred_bytes / time_spent;
>> max_size = bandwidth * migrate_max_downtime() / 100;
>>
>> -s->mbps = time_spent ? (((double) transferred_bytes * 8.0) /
>> -((double) time_spent / 1000.0)) / 1000.0 / 1000.0 : -1;
>> +s->mbps = (((double) transferred_bytes * 8.0) /
>> +((double) time_spent / 1000.0)) / 1000.0 / 1000.0;
>>
>> trace_migrate_transferred(transferred_bytes, time_spent,
>>bandwidth, max_size);
>>
--
Wei Yang
Help you, Help me
Re: [Qemu-devel] [PULL 9/9] kvm: shorten the parameter list for get_real_device()
Paolo,
Is it necessary to add this?
From: Wei Yang weiy...@linux.vnet.ibm.com
On Fri, Aug 23, 2013 at 11:03:35AM +0200, Paolo Bonzini wrote:
get_real_device() has 5 parameters with the last 4 is contained in the first
structure.
This patch removes the last 4 parameters and directly use them from the first
parameter.
Acked-by: Alex Williamson alex.william...@redhat.com
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/i386/kvm/pci-assign.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index ff33dc8..73941b2 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -568,8 +568,7 @@ static int get_real_device_id(const char *devpath,
uint16_t *val)
return get_real_id(devpath, device, val);
}
-static int get_real_device(AssignedDevice *pci_dev, uint16_t r_seg,
- uint8_t r_bus, uint8_t r_dev, uint8_t r_func)
+static int get_real_device(AssignedDevice *pci_dev)
{
char dir[128], name[128];
int fd, r = 0, v;
@@ -582,7 +581,8 @@ static int get_real_device(AssignedDevice *pci_dev,
uint16_t r_seg,
dev-region_number = 0;
snprintf(dir, sizeof(dir), /sys/bus/pci/devices/%04x:%02x:%02x.%x/,
- r_seg, r_bus, r_dev, r_func);
+ pci_dev-host.domain, pci_dev-host.bus,
+ pci_dev-host.slot, pci_dev-host.function);
snprintf(name, sizeof(name), %sconfig, dir);
@@ -1769,8 +1769,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
memcpy(dev-emulate_config_write, dev-emulate_config_read,
sizeof(dev-emulate_config_read));
-if (get_real_device(dev, dev-host.domain, dev-host.bus,
-dev-host.slot, dev-host.function)) {
+if (get_real_device(dev)) {
error_report(pci-assign: Error: Couldn't get real device (%s)!,
dev-dev.qdev.id);
goto out;
--
1.8.3.1
--
Richard Yang
Help you, Help me
Re: [Qemu-devel] [PULL 9/9] kvm: shorten the parameter list for get_real_device()
Paolo,
Sorry, maybe I am not familiar with the patch format in qemu-dev.
I didn't see the From: Wei Yang in this one neither.
On Fri, Aug 23, 2013 at 11:39:53AM +0200, Paolo Bonzini wrote:
get_real_device() has 5 parameters with the last 4 is contained in the first
structure.
This patch removes the last 4 parameters and directly use them from the first
parameter.
Acked-by: Alex Williamson alex.william...@redhat.com
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/i386/kvm/pci-assign.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index ff33dc8..73941b2 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -568,8 +568,7 @@ static int get_real_device_id(const char *devpath,
uint16_t *val)
return get_real_id(devpath, device, val);
}
-static int get_real_device(AssignedDevice *pci_dev, uint16_t r_seg,
- uint8_t r_bus, uint8_t r_dev, uint8_t r_func)
+static int get_real_device(AssignedDevice *pci_dev)
{
char dir[128], name[128];
int fd, r = 0, v;
@@ -582,7 +581,8 @@ static int get_real_device(AssignedDevice *pci_dev,
uint16_t r_seg,
dev-region_number = 0;
snprintf(dir, sizeof(dir), /sys/bus/pci/devices/%04x:%02x:%02x.%x/,
- r_seg, r_bus, r_dev, r_func);
+ pci_dev-host.domain, pci_dev-host.bus,
+ pci_dev-host.slot, pci_dev-host.function);
snprintf(name, sizeof(name), %sconfig, dir);
@@ -1769,8 +1769,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
memcpy(dev-emulate_config_write, dev-emulate_config_read,
sizeof(dev-emulate_config_read));
-if (get_real_device(dev, dev-host.domain, dev-host.bus,
-dev-host.slot, dev-host.function)) {
+if (get_real_device(dev)) {
error_report(pci-assign: Error: Couldn't get real device (%s)!,
dev-dev.qdev.id);
goto out;
--
1.8.3.1
--
Richard Yang
Help you, Help me
[Qemu-devel] [PATCH] kvm: shoten the parameter list for get_real_device()
get_real_device() has 5 parameters with the last 4 is contained in the first
structure.
This patch removes the last 4 parameters and directly use them from the first
parameter.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
hw/i386/kvm/pci-assign.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index 5618173..011764f 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -568,8 +568,7 @@ static int get_real_device_id(const char *devpath, uint16_t
*val)
return get_real_id(devpath, device, val);
}
-static int get_real_device(AssignedDevice *pci_dev, uint16_t r_seg,
- uint8_t r_bus, uint8_t r_dev, uint8_t r_func)
+static int get_real_device(AssignedDevice *pci_dev)
{
char dir[128], name[128];
int fd, r = 0, v;
@@ -582,7 +581,8 @@ static int get_real_device(AssignedDevice *pci_dev,
uint16_t r_seg,
dev-region_number = 0;
snprintf(dir, sizeof(dir), /sys/bus/pci/devices/%04x:%02x:%02x.%x/,
- r_seg, r_bus, r_dev, r_func);
+ pci_dev-host.domain, pci_dev-host.bus,
+ pci_dev-host.slot, pci_dev-host.function);
snprintf(name, sizeof(name), %sconfig, dir);
@@ -1769,8 +1769,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
memcpy(dev-emulate_config_write, dev-emulate_config_read,
sizeof(dev-emulate_config_read));
-if (get_real_device(dev, dev-host.domain, dev-host.bus,
-dev-host.slot, dev-host.function)) {
+if (get_real_device(dev)) {
error_report(pci-assign: Error: Couldn't get real device (%s)!,
dev-dev.qdev.id);
goto out;
--
1.7.5.4
[Qemu-devel] one question on the makefile
All, I saw a makefile rule which confused. This is in the tests/Makefile .PHONY: $(patsubst %, check-qtest-%, $(QTEST_TARGETS)) $(patsubst %, check-qtest-%, $(QTEST_TARGETS)): check-qtest-%: $(check-qtest-y) $(call quiet-command,QTEST_QEMU_BINARY=$*-softmmu/qemu-system-$* \ gtester $(GTESTER_OPTIONS) -m=$(SPEED) $(check-qtest-$*-y),GTESTER $@) I know the general idea is to create a rule for target such as check-qtest-x86_64. There are two colons, usually there is one colon in dependency. And the result dependency is check-qtest-x86_64: tests/fdc-test tests/rtc-test tests/cwd-test It is expanded to the content of check-qtest-x86_64-y. I searched the googl and makefile manual. Do not find a result. Could someone give me a hint? Thanks a lot. -- Richard Yang Help You, Help Me
Re: [Qemu-devel] Failed to set a breakpoint on start_kernel
2012/3/17 Jan Kiszka jan.kis...@web.de: [ re-added qemu-devel to CC ] On 2012-03-17 13:10, Wei Yang wrote: Two major issues with this procedure: 1. When using kvm, a soft breakpoint (as set by 'b') will inject a trap instruction into the guest image - which is not yet loaded after the bios ran. You need to use a hardware breakpoint in this case. 2. Due to gdb limitations, you cannot switch between 16/32-bit mode (the CPU starts in 16 bit) and the 64-bit mode of kernel within the same gdb session. Therefore: - let the target run into Linux is active - attach gdb - issue hw start_kernel - reboot (e.g. monitor system_reset) - you will hit the breakpoint, and gdb will be usable Jan oh, so when qemu run with kvm enabled, I couldn't debug the kernel right? That's not what I said. You need to be aware of how it works. And, in contrast to pure emulation, kwm uses a non-transparent mechanism for injecting software breakpoints. Consider it the price for the gained speed. Thanks :) It works. Though I don't understand it totally, I get the rough idea of it. :) I tried to run qemu with out -enable-kvm, kernel could stop at the break point. BTW, I tried hw start_kernel, but it failed. (gdb) hw start_kernel Undefined command: hw. Try help. Sorry, typo. Must be hb. Jan -- Richard Yang Help You, Help Me
Re: [Qemu-devel] Failed to set a breakpoint on start_kernel
You can also try my patch : http://patchwork.ozlabs.org/patch/137543/ Unless there is a use case beyond this x86 band-aid, lets focus on getting gdb right. Reminds me that gdb folks asked me to file a bug about this - which I still need to do. :-/ Jan Jan, I didn't try your patch yet. You mean this hardware assist break point is just support on x86 now? -- Richard Yang Help You, Help Me
[Qemu-devel] Failed to set a breakpoint on start_kernel
All I like qemu very much and know it could debug the kernel. I tried what I searched on web but couldn't stop at the break point. Below is what I did. 1. Both host and guest installed the same OS, Fedora16 x86_64. 2. Compile the qemu with ./configure --target-list=x86_64-softmmu --enable-kvm --enable-debug-tcg --enable-debug --enable-trace-backend=simple 3. With this command I can boot up my guest. ./../qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 1024 -boot dc fedora16.img -monitor stdio 4. I git clone the kernel source in the guest and make a new kernel and initrd. I start the guest with this new kernel successfully 5. I copy out the initrd.img and the .config of kernel to host. compile the kernel on host. the kernel source code is identical on host and gueset, 6. I start the guest with the kernel and initrd on host ./../qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 1024 -boot dc fedora16.img -monitor stdio -kernel ~/git/linux-yinghai/arch/x86_64/boot/bzImage -initrd ~/git/debug/initramfs-3.0.0.img -append root=/dev/mapper/vg_wizard-lv_root ro rd.lvm.lv=vg_wizard/lv_root rd.md=0 rd.lvm.lv=vg_wizard/lv_swap This works fine. 7. Then I start the guest with gdbstub option ./../qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 1024 -boot dc fedora16.img -monitor stdio -kernel /home/ywywyang/git/linux-yinghai/arch/x86_64/boot/bzImage -initrd /home/ywywyang/git/debug/initramfs-3.0.0.img -append root=/dev/mapper/vg_wizard-lv_root ro rd.lvm.lv=vg_wizard/lv_root rd.md=0 rd.lvm.lv=vg_wizard/lv_swap -S -gdb tcp::4321 Then the guest stop at the beginning. 8. Attach the gdb in the kernel source directory gdb file vmlinux target remote localhost:4321 b start_kernel c Then the guest will run very happily Also use the info b could show the break point is set. Which step I made a mistake? -- Wei Yang Help You, Help Me
[Qemu-devel] In OHCI the HC will sent packet to each attached port?
All
In function ohci_service_td() , there is a loop.
for (i = 0; i ohci-num_ports; i++) {
dev = ohci-rhport[i].port.dev;
if ((ohci-rhport[i].ctrl OHCI_PORT_PES) == 0)
continue;
if (ohci-async_td) {
/* ??? The hardware should allow one active packet per
endpoint. We only allow one active packet per controller.
This should be sufficient as long as devices respond in a
timely manner.
*/
#ifdef DEBUG_PACKET
DPRINTF(Too many pending packets\n);
#endif
return 1;
}
usb_packet_setup(ohci-usb_packet, pid,
OHCI_BM(ed-flags, ED_FA),
OHCI_BM(ed-flags, ED_EN));
usb_packet_addbuf(ohci-usb_packet, ohci-usb_buf, pktlen);
ret = usb_handle_packet(dev, ohci-usb_packet);
if (ret != USB_RET_NODEV)
break;
}
I searched the spec,
HcRhPortStatus:PES means This bit indicates whether the port is
enabled or disabled.
1 means enabled.
So for each td, HC will try to send packet on each port?
--
Richard Yang
Help You, Help Me
[Qemu-devel] Curious about this code in the ohci_service_td()
I am reading the code in ohci_service_td().
There is a calculation of the length of the buffer.
if ((td.cbp 0xf000) != (td.be 0xf000)) {
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
} else {
len = (td.be - td.cbp) + 1;
}
I am curious about the first case.
So the td.be could be less than the tb.cbp?
Seems this is a buffer ring and the size is around 4k?
--
Richard Yang
Help You, Help Me
Re: [Qemu-devel] Curious about this code in the ohci_service_td()
2012/2/19 Peter Maydell peter.mayd...@linaro.org:
On 18 February 2012 16:19, Wei Yang weiyang.ker...@gmail.com wrote:
I am reading the code in ohci_service_td().
There is a calculation of the length of the buffer.
if ((td.cbp 0xf000) != (td.be 0xf000)) {
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
} else {
len = (td.be - td.cbp) + 1;
}
I am curious about the first case.
So the td.be could be less than the tb.cbp?
Thanks Peter.
Yes. See the OHCI spec:
ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf
and specifically section 4.3: the data buffer described by a
TD may span two separate physically disjoint pages. The exact
I see this sentence. So this sentence means.
For example, I have
page 1
page 2
page 3
which contains the content of the TD. (In the guest I think.)
TD buffer could locate at page1 and page 3, without touching page 2?
And I am wondering, the buffer in the guest is page aligned or not?
In struct OHCIState, there is the usb_buf[8192].
I think this is the maximum packet size defined in the MPS field in the ED.
The size is exactly 2 pages, if the page is 4K.
This usb_buf is the buffer in the HC I think, so each time we use ohci_copy_td()
to get the content from the guest and put it in usb_buf.
Now come to my previous question again.
tb.cbp and tb.be is pointing to the address in the guest.
This means
tb.be may point to page 1
while
tb.cbp may point to page 3?
So tb.cbp tb.be?
page crossing behaviour is described more specifically in
section 4.3.1.3.1. (We don't implement it quite as described
there because we try to handle the whole data buffer at once
rather than byte-by-byte, but the effect is the same. See
also the code later on in the function under 'Transmission
succeeded' which updates td.cbp to the right value if we only
managed to send part of the data.)
I quoted it from the specification.
===
If during the data transfer the buffer address contained in the HC’s
working copy of
CurrentBufferPointer crosses a 4K boundary, the upper 20 bits of
Buffer End are copied to the
working value of CurrentBufferPointer causing the next buffer address
to be the 0th byte in the
same 4K page that contains the last byte of the buffer (the 4K
boundary crossing may occur
within a data packet transfer.)
===
As I asked before, if the buffer is paged aligned, the
CurrentBufferPointer is pointing to the
beginning of one page.
Since the MPS is 8K, so Buffer End just has two cases.
Page A Page B
|---||---|
^ ^ ^
| | case 1 | case 2
cbp bebe
PageA and PageB are disjoint pages.
For case 1, it is easy to calculate the buffer size.
For case 2, since the page maybe disjoint, so after copy the first page,
cbp is set to the start of the next page. If we just calculate
cbp = cbp + 0x1000
this may not be the start address of PageB.
I think my assumption is based on
1. buffer size is less than the MPS, which is 8k.
2. the cbp is page aligned.
Hmm I looked at the code again.
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
If cbp is page aligned, then no need to do (td.cbp 0xfff)?
-- PMM
--
Richard Yang
Help You, Help Me
[Qemu-devel] how could I analysis the trace log?
All I enable the trace function with --enable-trace-backend=simple and I create the event file like this g_realloc g_malloc Then I start the qemu with following command. ./i386-softmmu/qemu-system-i386 -enable-kvm -drive file=../../kvm/ubuntu.img -boot dc -m 512 -usb -monitor stdio -trace events=qemu_trace_events,file=qemu_trace.log After some run time, I run the script like: ./scripts/simpletrace.py qemu_trace_events_parse qemu_trace.log The qemu_trace_events_parse is : g_realloc(addr) g_malloc(addr) The output looks like: g_malloc 1.831 addr=0xb945d1f0 g_malloc 2.498 addr=0xb945d1f0 g_realloc 4.715 addr=0x10 g_realloc 1.520 addr=0xc g_realloc 1.505 addr=0xc The steps I used is correct? I just guess the format of input events file of the simpletrace.py. For so many available events, how could I specify the format of all those events? -- Richard Yang Help You, Help Me
Re: [Qemu-devel] How to follow a child process created in the guest OS?
2012/2/11 malc av1...@comtv.ru:
On Sat, 11 Feb 2012, Andreas F?rber wrote:
Am 10.02.2012 11:26, schrieb ???:
On Fri, Feb 10, 2012 at 08:14:41AM +, Stefan Hajnoczi wrote:
On Thu, Feb 09, 2012 at 06:33:16PM +0800, ??? wrote:
I am running a tiny OS on QEMU and debugging it with gdbstub. The tiny
OS will
fork process 1, 2, ... and so on. I want to follow the child process,
[...]
Is there a way to do what I'm trying to do? Thanks!
- Tiny OS code -
void main(void) /* This really IS void, no error here. */
{
/* initialize enviroment */
sti();
move_to_user_mode();
if (!fork()) { /* we count on this going ok */
init(); // task 1
}
for(;;) pause(); // task 0
}
I am running this tiny OS on QEMU then using GDB to connect it.
I want to follow task 1 after the forking, [...]
Could the Qemu gdbstub debug a user space process?
--
Richard Yang
Help You, Help Me
Re: [Qemu-devel] how could I analysis the trace log?
Hi, this kind of trace is not popular? 2012/2/12 Wei Yang weiyang.ker...@gmail.com: All I enable the trace function with --enable-trace-backend=simple and I create the event file like this g_realloc g_malloc Then I start the qemu with following command. ./i386-softmmu/qemu-system-i386 -enable-kvm -drive file=../../kvm/ubuntu.img -boot dc -m 512 -usb -monitor stdio -trace events=qemu_trace_events,file=qemu_trace.log After some run time, I run the script like: ./scripts/simpletrace.py qemu_trace_events_parse qemu_trace.log The qemu_trace_events_parse is : g_realloc(addr) g_malloc(addr) The output looks like: g_malloc 1.831 addr=0xb945d1f0 g_malloc 2.498 addr=0xb945d1f0 g_realloc 4.715 addr=0x10 g_realloc 1.520 addr=0xc g_realloc 1.505 addr=0xc The steps I used is correct? I just guess the format of input events file of the simpletrace.py. For so many available events, how could I specify the format of all those events? -- Richard Yang Help You, Help Me -- Richard Yang Help You, Help Me
[Qemu-devel] [PATCH] This patch is used to move some struct definition, like QEMUTimer, QEMUClock, from .c to .h.
Tested on i386 platform.
Signed-off-by: Wei Yangweiy...@linux.vnet.ibm.com
---
qemu-timer.c | 40
qemu-timer.h | 41 +
2 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..2b5cc48 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -46,46 +46,6 @@
#include qemu-timer.h
-/***/
-/* timers */
-
-#define QEMU_CLOCK_REALTIME 0
-#define QEMU_CLOCK_VIRTUAL 1
-#define QEMU_CLOCK_HOST 2
-
-struct QEMUClock {
-int type;
-int enabled;
-
-QEMUTimer *active_timers;
-
-NotifierList reset_notifiers;
-int64_t last;
-};
-
-struct QEMUTimer {
-QEMUClock *clock;
-int64_t expire_time; /* in nanoseconds */
-int scale;
-QEMUTimerCB *cb;
-void *opaque;
-struct QEMUTimer *next;
-};
-
-struct qemu_alarm_timer {
-char const *name;
-int (*start)(struct qemu_alarm_timer *t);
-void (*stop)(struct qemu_alarm_timer *t);
-void (*rearm)(struct qemu_alarm_timer *t, int64_t nearest_delta_ns);
-#if defined(__linux__)
-int fd;
-timer_t timer;
-#elif defined(_WIN32)
-HANDLE timer;
-#endif
-char expired;
-char pending;
-};
static struct qemu_alarm_timer *alarm_timer;
diff --git a/qemu-timer.h b/qemu-timer.h
index 67ca72e..5bf2fc7 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -20,6 +20,47 @@
typedef struct QEMUClock QEMUClock;
typedef void QEMUTimerCB(void *opaque);
+/***/
+/* timers */
+
+#define QEMU_CLOCK_REALTIME 0
+#define QEMU_CLOCK_VIRTUAL 1
+#define QEMU_CLOCK_HOST 2
+
+struct QEMUClock {
+int type;
+int enabled;
+
+QEMUTimer *active_timers;
+
+NotifierList reset_notifiers;
+int64_t last;
+};
+
+struct QEMUTimer {
+QEMUClock *clock;
+int64_t expire_time; /* in nanoseconds */
+int scale;
+QEMUTimerCB *cb;
+void *opaque;
+struct QEMUTimer *next;
+};
+
+struct qemu_alarm_timer {
+char const *name;
+int (*start)(struct qemu_alarm_timer *t);
+void (*stop)(struct qemu_alarm_timer *t);
+void (*rearm)(struct qemu_alarm_timer *t, int64_t nearest_delta_ns);
+#if defined(__linux__)
+int fd;
+timer_t timer;
+#elif defined(_WIN32)
+HANDLE timer;
+#endif
+char expired;
+char pending;
+};
+
/* The real time clock should be used only for stuff which does not
change the virtual machine state, as it is run even if the virtual
machine is stopped. The real time clock has a frequency of 1000
--
1.7.4.1
