When i use the savevm command to create a online snapshot i found it's very very slow,i found the online snapshot save four device information,and now i only want to save the disk information so i delete the code to save the other three device information,however,i found
when the disk
capacity is big it's also very slow ,could you offer some ideas to solve this problem?THX by Wenchao Gong
At 2013-11-03 21:28:26,address@hidden wrote:
>Send Qemu-devel mailing list submissions to
> address@hidden
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/qemu-devel
>or, via email, send a message with subject or body 'help' to
> address@hidden
>
>You can reach the person managing the list at
> address@hidden
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Qemu-devel digest..."
>
>
>Today's Topics:
>
> 1. [Bug 1247478] [NEW] usb passthrough mass storage write data
> corruption (Sascha Krissler)
> 2. Re: [RFC PATCH] spapr: add ibmveth to the supported network
> adapters list (Alexander Graf)
> 3. Re: savevm/loadvm (Alexey Kardashevskiy)
> 4. [migration] questions about removing the old block-migration
> code (Zhanghaoyu (A))
> 5. Re: [PATCH] qemu-ga: vss-win32: Install VSS provider COM+
> application service (Gal Hammer)
> 6. Trace ARM PC (Xin Tong)
> 7. Re: [PULL v2 00/56] QOM devices patch queue 2013-10-31
> (Andreas F?rber)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 02 Nov 2013 21:34:39 -0000
>From: Sascha Krissler <address@hidden>
>To: address@hidden
>Subject: [Qemu-devel] [Bug 1247478] [NEW] usb passthrough mass storage
> write data corruption
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset="utf-8"
>
>Public bug reported:
>
>the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb
>in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and
>except for the last packet for odd-sized files). The pattern is:
>3 times bulk out 20480
>1 time bulk out 4096
>
>and that repeats for files longer than 65536 bytes.
>
>the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each
>20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and
>57344-61440.
>and so on. and because the 4096 sized bulk out is always error free, the next corrupt span is from
>81920-86016.
>
>the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same
>transfer.
>
>to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file.
>(possibly check the bulk transfer sizes with usbmon).
>note that attaching usb disks with hw/usb/dev-storage does work just fine.
>cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are
>always ok even with usb passthrough.
>
>** Affects: qemu
> Importance: Undecided
> Status: New
>
>--
>You received this bug notification because you are a member of qemu-
>devel-ml, which is subscribed to QEMU.
>https://bugs.launchpad.net/bugs/1247478
>
>Title:
> usb passthrough mass storage write data corruption
>
>Status in QEMU:
> New
>
>Bug description:
> the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb
> in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and
> except for the last packet for odd-sized files). The pattern is:
> 3 times bulk out 20480
> 1 time bulk out 4096
>
> and that repeats for files longer than 65536 bytes.
>
> the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each
> 20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and
> 57344-61440.
> and so on. and because the 4096 sized bulk out is always error free, the next corrupt span is from
> 81920-86016.
>
> the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same
> transfer.
>
> to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file.
> (possibly check the bulk transfer sizes with usbmon).
> note that attaching usb disks with hw/usb/dev-storage does work just fine.
> cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are
> always ok even with usb passthrough.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/qemu/+bug/1247478/+subscriptions
>
>
>
>------------------------------
>
>Message: 2
>Date: Sat, 2 Nov 2013 23:52:58 +0100
>From: Alexander Graf <address@hidden>
>To: Markus Armbruster <address@hidden>
>Cc: Alexey Kardashevskiy <address@hidden>, "address@hidden"
> <address@hidden>, "address@hidden:PReP" <address@hidden>, QEMU
> Developers <address@hidden>, Anthony Liguori
> <address@hidden>
>Subject: Re: [Qemu-devel] [RFC PATCH] spapr: add ibmveth to the
> supported network adapters list
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>
>
>Am 02.11.2013 um 12:51 schrieb Markus Armbruster <address@hidden>:
>
>> Alexander Graf <address@hidden> writes:
>>
>>> Am 01.11.2013 um 03:52 schrieb Alexey Kardashevskiy <address@hidden>:
>> [...]
>>>> Or "-net" interface is "deprecated" and we do not want even touch it?
>>>
>>> I don't think we should deprecate it. It's easier to use than anything
>>> else. Ahci adoption heavily suffered from not being enabled in -drive
>>> - I don't want that again here.
>>
>> How exactly is
>>
>> -net nic,netdev=NET-ID,macaddr=MACADDR,model=MODEL,...
>>
>> easier to use than
>>
>> -device DEVNAME,netdev=NET-ID,macaddr=MACADDR,...
>>
>> ?
>>
>> Especially now that -device help shows valid DEVNAMEs under the heading
>> "Network devices".
>
>The same way -device ahci -drive ...,if=none -device ide-drive,... Is harder than -drive if=ahci. Users didn't even realize ahci support was in the code base...
>
>
>Alex
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Sun, 03 Nov 2013 11:34:14 +1100
>From: Alexey Kardashevskiy <address@hidden>
>To: Max Reitz <address@hidden>, "address@hidden"
> <address@hidden>
>Cc: Kevin Wolf <address@hidden>
>Subject: Re: [Qemu-devel] savevm/loadvm
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=KOI8-R
>
>On 11/02/2013 01:16 AM, Max Reitz wrote:
>> Hi,
>>
>> Sorry I'm just now replying to this. I ran into the same issue (and
>> another one) and it should be fixed by the upstream commits
>> eedff66f21e542650d895801549ce05ac108278b and
>> 6e13610aa454beba52944e8df6d93158d68ab911. Those have been merged to
>> master yesterday, so could you re-build qemu from master and try again?
>
>
>Yes, this works now, thanks!
>
>
>> Kind regards,
>>
>> Max
>>
>>
>> On 08.10.2013 10:40, Alexey Kardashevskiy wrote:
>>> Hi!
>>>
>>> I need the community help with savevm/loadvm.
>>>
>>> I run QEMU like this:
>>>
>>> ./qemu-system-ppc64 \
>>> -drive file=virtimg/fc19_16GB.qcow2 \
>>> -nodefaults \
>>> -m "2048" \
>>> -machine "pseries" \
>>> -nographic \
>>> -vga "none" \
>>> -enable-kvm
>>>
>>>
>>> The disk image is an 16GB qcow2 image.
>>>
>>> Now I start the guest and do "savevm 1" and "loadvm 1" from the qemu
>>> console. Everything works. Then I exit qemu, make sure that the snapshot is
>>> there and run QEMU as above plus "-loadvm 1". It fails with:
>>>
>>> qemu-system-ppc64: qcow2: Loading snapshots with different disk size is not
>>> implemented
>>> qemu-system-ppc64: Error -95 while activating snapshot '2' on 'scsi0-hd0'
>>>
>>> The check is added by commit 90b277593df873d3a2480f002e2eb5fe1f8e5277
>>> "qcow2: Save disk size in snapshot header".
>>>
>>> As I cannot realize the whole idea of the patch, I looked a bit deeper.
>>> This is the check:
>>>
>>> int qcow2_snapshot_goto(BlockDriverState *bs, const char *snapshot_id)
>>> {
>>> [...]
>>> if (sn->disk_size != bs->total_sectors * BDRV_SECTOR_SIZE) {
>>> error_report("qcow2: Loading snapshots with different disk "
>>> "size is not implemented");
>>> ret = -ENOTSUP;
>>> goto fail;
>>> }
>>>
>>>
>>> My understanding of the patch was that the disk_size should remain 16GB
>>> (0x4.0000.0000) as it uses bs->total_sectors and never changes it. And
>>> bs->growable is 0 for qcow2 image because it is not really growable. At
>>> least the total_sectors value from the qcow2 file header does not change
>>> between QEMU starts.
>>>
>>> However qcow2_save_vmstate() sets bs->growable to 1 for a short time
>>> (commit 178e08a58f40dd5aef2ce774fe0850f5d0e56918 from 2009) and this
>>> triggers a branch in bdrv_co_do_writev() which changes bs->total_sectors.
>>> So when QEMU writes snapshots to the file, the disk_size field of a
>>> snapshot has bigger value (for example 0x4.007b.8180).
>>>
>>> And the check above fails. It does not fail if to do "loadvm"
>>> _in_the_same_run_ after "savevm" because QEMU operates with the updated
>>> bs->total_sectors.
>>>
>>> What the proper fix would be? Or it is not a bug at all and I should be
>>> using something else for "-loadvm"? Thanks.
>>>
>>>
>>>
>>
>
>
>--
>Alexey
>
>
>
>------------------------------
>
>Message: 4
>Date: Sun, 3 Nov 2013 04:01:36 +0000
>From: "Zhanghaoyu (A)" <address@hidden>
>To: "address@hidden" <address@hidden>
>Cc: "Huangweidong \(C\)" <address@hidden>, "Michael S.
> Tsirkin" <address@hidden>, Michal Privoznik <address@hidden>,
> Marcelo Tosatti <address@hidden>, "address@hidden"
> <address@hidden>, "address@hidden"
> <address@hidden>, Xiahai <address@hidden>, Linqiangmin
> <address@hidden>, Zanghongyong <address@hidden>,
> Luonengjun <address@hidden>, "Huangpeng \(Peter\)"
> <address@hidden>
>Subject: [Qemu-devel] [migration] questions about removing the old
> block-migration code
>Message-ID:
> <address@hidden>
>
>Content-Type: text/plain; charset="us-ascii"
>
>Hi, Juan
>
>I read below words on the report of <KVM Live Migration: Weather forecast (May 29, 2013)>,
>We were going to remove the old block-migration code
>Then people fixed it
>Good: it works now
>Bad: We have to maintain both
>It uses the same port than migration
>You need to migrate all/none of block devices
>
>The old block-migration code said above is that in block-migration.c?
>What are the reasons of removing the old block-migration code? Buggy implementation? Or need to migrate all/none of block devices?
>What's the substitutional method? drive_mirror?
>
>Thanks,
>Zhang Haoyu
>
>
>
>------------------------------
>
>Message: 5
>Date: Sun, 03 Nov 2013 11:59:49 +0200
>From: Gal Hammer <address@hidden>
>To: Tomoki Sekiyama <address@hidden>, address@hidden
>Cc: address@hidden, address@hidden,
> address@hidden, address@hidden, address@hidden
>Subject: Re: [Qemu-devel] [PATCH] qemu-ga: vss-win32: Install VSS
> provider COM+ application service
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>Reviewed-by: Gal Hammer <address@hidden>
>
>On 01/11/2013 23:47, Tomoki Sekiyama wrote:
>> Currently, qemu-ga for Windows fails to execute guset-fsfreeze-freeze when
>> no user is logging in to Windows, with an error message:
>> {"error":{"class":"GenericError",
>> "desc":"failed to add C:\\ to snapshotset: (error: 8004230f)"}}
>>
>> To enable guest-fsfreeze-freeze/thaw without logging in users, this installs
>> a service to execute qemu-ga VSS provider COM+ application that has full
>> access privileges to the local system. The service will automatically be
>> removed when the COM+ application is deregistered.
>>
>> This patch replaces ICOMAdminCatalog interface with ICOMAdminCatalog2
>> interface that contains CreateServiceForApplication() method in addition.
>>
>> Signed-off-by: Tomoki Sekiyama <address@hidden>
>> ---
>> qga/vss-win32/install.cpp | 16 ++++++++++------
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/qga/vss-win32/install.cpp b/qga/vss-win32/install.cpp
>> index 37731a7..b791a6c 100644
>> --- a/qga/vss-win32/install.cpp
>> +++ b/qga/vss-win32/install.cpp
>> @@ -25,8 +25,8 @@ extern HINSTANCE g_hinstDll;
>>
>> const GUID CLSID_COMAdminCatalog = { 0xF618C514, 0xDFB8, 0x11d1,
>> {0xA2, 0xCF, 0x00, 0x80, 0x5F, 0xC7, 0x92, 0x35} };
>> -const GUID IID_ICOMAdminCatalog = { 0xDD662187, 0xDFC2, 0x11d1,
>> - {0xA2, 0xCF, 0x00, 0x80, 0x5F, 0xC7, 0x92, 0x35} };
>> +const GUID IID_ICOMAdminCatalog2 = { 0x790C6E0B, 0x9194, 0x4cc9,
>> + {0x94, 0x26, 0xA4, 0x8A, 0x63, 0x18, 0x56, 0x96} };
>> const GUID CLSID_WbemLocator = { 0x4590f811, 0x1d3a, 0x11d0,
>> {0x89, 0x1f, 0x00, 0xaa, 0x00, 0x4b, 0x2e, 0x24} };
>> const GUID IID_IWbemLocator = { 0xdc12a687, 0x737f, 0x11cf,
>> @@ -141,7 +141,7 @@ static HRESULT QGAProviderFind(
>> HRESULT hr;
>> COMInitializer initializer;
>> COMPointer<IUnknown> pUnknown;
>> - COMPointer<ICOMAdminCatalog> pCatalog;
>> + COMPointer<ICOMAdminCatalog2> pCatalog;
>> COMPointer<ICatalogCollection> pColl;
>> COMPointer<ICatalogObject> pObj;
>> _variant_t var;
>> @@ -149,7 +149,7 @@ static HRESULT QGAProviderFind(
>>
>> chk(CoCreateInstance(CLSID_COMAdminCatalog, NULL, CLSCTX_INPROC_SERVER,
>> IID_IUnknown, (void **)pUnknown.replace()));
>> - chk(pUnknown->QueryInterface(IID_ICOMAdminCatalog,
>> + chk(pUnknown->QueryInterface(IID_ICOMAdminCatalog2,
>> (void **)pCatalog.replace()));
>> chk(pCatalog->GetCollection(_bstr_t(L"Applications"),
>> (IDispatch **)pColl.replace()));
>> @@ -206,7 +206,7 @@ STDAPI COMRegister(void)
>> HRESULT hr;
>> COMInitializer initializer;
>> COMPointer<IUnknown> pUnknown;
>> - COMPointer<ICOMAdminCatalog> pCatalog;
>> + COMPointer<ICOMAdminCatalog2> pCatalog;
>> COMPointer<ICatalogCollection> pApps, pRoles, pUsersInRole;
>> COMPointer<ICatalogObject> pObj;
>> long n;
>> @@ -229,7 +229,7 @@ STDAPI COMRegister(void)
>>
>> chk(CoCreateInstance(CLSID_COMAdminCatalog, NULL, CLSCTX_INPROC_SERVER,
>> IID_IUnknown, (void **)pUnknown.replace()));
>> - chk(pUnknown->QueryInterface(IID_ICOMAdminCatalog,
>> + chk(pUnknown->QueryInterface(IID_ICOMAdminCatalog2,
>> (void **)pCatalog.replace()));
>>
>> /* Install COM+ Component */
>> @@ -273,6 +273,10 @@ STDAPI COMRegister(void)
>> goto out;
>> }
>>
>> + chk(pCatalog->CreateServiceForApplication(
>> + _bstr_t(QGA_PROVIDER_LNAME), _bstr_t(QGA_PROVIDER_LNAME),
>> + _bstr_t(L"SERVICE_AUTO_START"), _bstr_t(L"SERVICE_ERROR_NORMAL"),
>> + _bstr_t(L""), _bstr_t(L".\\localsystem"), _bstr_t(L""), FALSE));
>> chk(pCatalog->InstallComponent(_bstr_t(QGA_PROVIDER_LNAME),
>> _bstr_t(dllPath), _bstr_t(tlbPath),
>> _bstr_t("")));
>>
>
>
>
>
>------------------------------
>
>Message: 6
>Date: Sun, 3 Nov 2013 02:31:40 -0800
>From: Xin Tong <address@hidden>
>To: address@hidden
>Subject: [Qemu-devel] Trace ARM PC
>Message-ID:
> <address@hidden>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi.
>
>I would like to trace all the executed instruction PC in QEMU ARM. Because
>ARM has conditional execution, we do not know whether an instruction will
>execute or not at translation time. Therefore the PC tracing code can not
>be generated before the instruction is disassembled. (i.e. before
>disas_thumb_insn/disas_arm_insn ). Then, is it correct to generate the PC
>tracing code after the disas_XXX_insn functions are called ? I can keep
>the old value of the PC before the PC in the disassemble context is updated
>by the disas_XXX_insn.
>
>I think this would work for normal instructions, but probably not for
>branches, so the PC tracing has to be done before the branch in the
>disas_XXX_insn functions ? can anyone please confirm ?
>
>Thank you,
>Xin
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.nongnu.org/archive/html/qemu-devel/attachments/20131103/f7b974d7/attachment.html>
>
>------------------------------
>
>Message: 7
>Date: Sun, 03 Nov 2013 14:28:03 +0100
>From: Andreas F?rber <address@hidden>
>To: Anthony Liguori <address@hidden>, "Michael S. Tsirkin"
> <address@hidden>
>Cc: Peter Maydell <address@hidden>, "Mian M. Hamayun"
> <address@hidden>, qemu-devel
> <address@hidden>, Stefan Hajnoczi <address@hidden>, Paolo
> Bonzini <address@hidden>, "Edgar E. Iglesias"
> <address@hidden>
>Subject: Re: [Qemu-devel] [PULL v2 00/56] QOM devices patch queue
> 2013-10-31
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset=ISO-8859-1
>
>Anthony,
>
>Am 31.10.2013 22:03, schrieb Anthony Liguori:
>> On Thu, Oct 31, 2013 at 3:37 PM, Andreas F?rber <address@hidden> wrote:
>>> Hello Anthony,
>>>
>>> This is my updated QOM devices patch queue. Please pull or provide more details
>>> of what is not working in your build environment.
>>
>> Andreas,
>>
>> If you cannot be bothered to adequately test your pull requests, then
>> don't bother sending them.
>
>You want to be rude? I can be rude, too. Who merged the block pull that
>according to the qtests I provided broke several machines? You. Your
>testing is not perfect either, so watch your language.
>
>In particular since Friday make check fails on qemu.git:
>
>GTESTER check-qtest-arm
>GTESTER check-qtest-i386
>main-loop: WARNING: I/O thread spun for 1000 iterations
>main-loop: WARNING: I/O thread spun for 1000 iterations
>blkdebug: Suspended request 'A'
>blkdebug: Resuming request 'A'
>main-loop: WARNING: I/O thread spun for 1000 iterations
>main-loop: WARNING: I/O thread spun for 1000 iterations
>GTESTER check-qtest-mips64el
>qemu-system-mips64el: /home/andreas/QEMU/qemu-cpu/exec.c:802:
>register_subpage: Assertion `existing->mr->subpage || existing->mr ==
>&io_mem_unassigned' failed.
>Broken pipe
>GTester: last random seed: R02S52ce3c776bf01d96752819c947c85576
>qemu-system-mips64el: /home/andreas/QEMU/qemu-cpu/exec.c:802:
>register_subpage: Assertion `existing->mr->subpage || existing->mr ==
>&io_mem_unassigned' failed.
>Broken pipe
>GTester: last random seed: R02S65379793c25d23b7d98dc1032139cc63
>qemu-system-mips64el: /home/andreas/QEMU/qemu-cpu/exec.c:802:
>register_subpage: Assertion `existing->mr->subpage || existing->mr ==
>&io_mem_unassigned' failed.
>Broken pipe
>GTester: last random seed: R02Sa11769e1b4918ba79a24beeb22c829ae
>make: *** [check-qtest-mips64el] Fehler 1
>
>git-bisect says this:
>
>a53ae8e934cd54686875b5bcfc2f434244ee55d6 is the first bad commit
>commit a53ae8e934cd54686875b5bcfc2f434244ee55d6
>Author: Marcel Apfelbaum <address@hidden>
>Date: Mon Sep 16 11:21:16 2013 +0300
>
> hw/pci: partially handle pci master abort
>
> A MemoryRegion with negative priority was created and
> it spans over all the pci address space.
> It "intercepts" the accesses to unassigned pci
> address space and will follow the pci spec:
> 1. returns -1 on read
> 2. does nothing on write
>
> Note: setting the RECEIVED MASTER ABORT bit in the STATUS register
> of the device that initiated the transaction will be
> implemented in another series
>
> Signed-off-by: Marcel Apfelbaum <address@hidden>
> Acked-by: Michael S. Tsirkin <address@hidden>
> Signed-off-by: Michael S. Tsirkin <address@hidden>
>
>:040000 040000 b115d38ba08642a56300da49bfe7e3e7148eb20d
>b364a5cfb65ffbf4e83cadaa0afeb9922aec331b M hw
>:040000 040000 d0b3d397bb819cdbfd66ca0c199c62bd55f2db9e
>263f0822e4d4a078bd772c8a84e113e1c28bbad9 M include
>
>I.e. the first pull you've merged after Edgar doesn't pass make check!
>
>But worse, my qom-test shows that isapc asserts, too:
>
>GTESTER check-qtest-i386
>main-loop: WARNING: I/O thread spun for 1000 iterations
>main-loop: WARNING: I/O thread spun for 1000 iterations
>blkdebug: Suspended request 'A'
>blkdebug: Resuming request 'A'
>main-loop: WARNING: I/O thread spun for 1000 iterations
>qemu-system-i386: /home/andreas/QEMU/qemu/hw/i386/acpi-build.c:135:
>acpi_get_pm_info: Assertion `obj' failed.
>Broken pipe
>GTester: last random seed: R02Sdbc8da98b2e9405d3ac769aca1780a25
>make: *** [check-qtest-i386] Fehler 1
>
>So it would be really good to have those tests in qemu.git and actually
>run! You already didn't take them for 1.6 and back then you didn't
>report any breakage at all. We only had a discussion about how to handle
>lack of arguments, which Aur?lien ended by reverting changes to mips and
>insisting that missing arguments continue to be errors.
>
>> make check fails spectacularly. I've confirmed this on multiple
>> platforms on different distros.
>
>You have pastebin'ed me a really non-telling snippet. I have already
>showed you that on my side (openSUSE 12.3 w/ 3.12 kernel) make check
>succeeded just fine, same for v2 or I wouldn't have sent it. You should
>know me well enough for that!!!
>
>So it's definitely not me being sloppy but some environmental difference
>between our setups. And I have repeatedly asked you on IRC about your
>setup without getting further replies. Show me what to fix and I can
>look into fixing it.
>
>All I could come up with was some non-fatal audio error messages
>depending on QEMU_AUDIO_DRV environment variable. No comparison to the
>actual breakages that we are seeing in qemu.git now.
>
>> The errors are the exact same as before. Install some VMs and
>> reproduce the problem. I just checked and it fails under 64-bit
>> Fedora 19.
>
>I have successfully booted up openSUSE 12.3 x86_64 and SLES 11 SP3
>x86_64 without any issue. You really need to explain "the problem"!
>
>Regards,
>Andreas
>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> v2 is rebased, dropping two ARM patches, and the observed SD segfault had been
>>> fixed in 794cbc26eb94ce13c75d105eea9ff0afff56e2c2.
>>> Patches are not manually changed, thus intentionally not resent.
>>>
>>> Thanks,
>>> Andreas
>
>--
>SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
>GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
>
>
>
>------------------------------
>
>_______________________________________________
>Qemu-devel mailing list
>address@hidden
>https://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>End of Qemu-devel Digest, Vol 128, Issue 24
>*******************************************