[Qemu-devel] GSoC - Tracepoint support for the gdbstub
Hello all, I am Mitnick Lyu, who want to contribute to QEMU and participate Google Summer of Code this year. I have some experience with tool-chain developing and I am highly interested in the project: Tracepoint support for the gdbstub. I am wondering to know whether there is someone working for this project. Thanks a lot
[Qemu-devel] Execute QEMU "the same"
Hello all, I am wondering to know whether QEMU could run "the same" twice. ie. the same of execution trace. I read the user manual and find options like: "-clock dynticks -rtc base=2006-06-17T16:01:21,clock=vm -icount 1". Would QEMU run "the same" with these options?? PS. I also found the function cpu_io_recompile() with comments: /* in deterministic execution mode, instructions doing device I/Os must be at the end of the TB */ But I don't know the means of deterministic execution mode and how to turn on it. thanks a lot Mitnick
[Qemu-devel] Question about (next_tb & 3) == 2
Hello all,
I am a newbie of QEMU and wondering to know the meaning of:
if ((next_tb & 3) == 2) {
/* Instruction counter expired. */
int insns_left;
tb = (TranslationBlock *)(long)(next_tb & ~3);
/* Restore PC. */
cpu_pc_from_tb(env, tb);
insns_left = env->icount_decr.u32;
if (env->icount_extra && insns_left >= 0) {
/* Refill decrementer and continue execution. */
env->icount_extra += insns_left;
if (env->icount_extra > 0x) {
insns_left = 0x;
} else {
insns_left = env->icount_extra;
}
env->icount_extra -= insns_left;
env->icount_decr.u16.low = insns_left;
} else {
if (insns_left > 0) {
/* Execute remaining instructions. */
cpu_exec_nocache(insns_left, tb);
}
env->exception_index = EXCP_INTERRUPT;
next_tb = 0;
cpu_loop_exit();
}
}
in cpu-exec.c:cpu_exec().
There are two mode of QEMU: without io-thread and with io-thread. Which mode
and what condition cause execution of the code list above??
Thanks a lot
Mitnick
[Qemu-devel] GSoC: Improved image format compatibility
Hello all, I have used QEMU to assist me developing embedded system for 3 years. And I want to contribute to QEMU and participate Google Summer of Code this year. I have port binutils so I have some experienced with binary format. I noticed that there is no VHD support in qemu-img. A Virtual Hard Disk(VHD) is a virtual hard disk file format used in Microsoft virtual PC, Hyper-V, virtual box, xVM and Complete PC Backup of vista and windows 7. I want to add support for VHD in GSoC. I am wondering whether this kind of idea is valuable to QEMU?? Or any another topic related image format is valuable to QEMU?? thanks Mitnick
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello Stefan, I have spent a whole night to trace the code of block/vpc.c and compare against the VHD specifications (at http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C2D03242-2FFB-48EF-A211-F0C44741109E&displaylang=en ). It seems that there isn't Fixed hard disk image and Differencing hard disk image support now. I am wondering whether what I has learned from tracing code is true or false? I also found some possibility of optimization in block/vpc.c. Should I contact mentor assigned to this project in private or post the whole idea on the mailing list?? thanks very much Mitnick 2011/3/30 Stefan Hajnoczi > On Wed, Mar 30, 2011 at 5:50 AM, Stefan Weil wrote: > > Am 29.03.2011 23:55, schrieb Lyu Mitnick: > >> > >> Hello all, > >> > >> I have used QEMU to assist me developing embedded system for 3 years. > And > >> I > >> want to contribute to QEMU and participate Google Summer of Code this > >> year. > >> I have port binutils so I have some experienced with binary format. I > >> noticed that there is no VHD support in qemu-img. A Virtual Hard > Disk(VHD) > >> is a virtual hard disk file format used in Microsoft virtual PC, > Hyper-V, > >> virtual box, xVM and Complete PC Backup of vista and windows 7. I want > to > >> add support for VHD in GSoC. I am wondering whether this kind of idea is > >> valuable to QEMU?? Or any another topic related image format is valuable > >> to > >> QEMU?? > >> > >> thanks > >> > >> Mitnick > > > > Hello Mitnick, > > > > QEMU (including qemu-img) already supports the format vpc. > > The code in block/vpc.c also uses the name vhd, so I think > > vpc == vhd. > > However, it is possible that vpc/vhd has new features that are not yet > supported in QEMU. There is a listed project idea for updating image > formats on the GSoC wiki page: > > > http://wiki.qemu.org/Google_Summer_of_Code_2011#Improved_image_format_compatibility > > You could assess QEMU's implementation in block/vpc.c and compare > against the latest public file format specification: > > http://en.wikipedia.org/wiki/VHD_(file_format) > > If you find there are new features or format changes that are not yet > supported in QEMU, this might make a good "Improved image format > compatibility" GSoC project. > > Stefan >
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello Stefan, Let me summarize the ideas of "Improved image format compatibility" now: (1) add support of "Fixed hard disk image" into block/vpc.c (2) add support of "Differencing hard disk image" into block/vpc.c (3) add asynchronous i/o into block/vpc,c (4) have some optimization of block/vpc.c Would you mind to tell me the project containing four topics above is suitable for GSoC of size and skill level?? And would anyone is interested in this project and being my mentor?? thanks very much 2011/3/31 Stefan Weil > Am 30.03.2011 20:40, schrieb Lyu Mitnick: > >> Hello Stefan, >> >> I have spent a whole night to trace the code of block/vpc.c and compare >> against the VHD specifications >> (at >> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C2D03242-2FFB-48EF-A211-F0C44741109E&displaylang=en<http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C2D03242-2FFB-48EF-A211-F0C44741109E&displaylang=en>< >> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C2D03242-2FFB-48EF-A211-F0C44741109E&displaylang=en<http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C2D03242-2FFB-48EF-A211-F0C44741109E&displaylang=en> >> >). >> >> It seems that there isn't Fixed hard disk image and Differencing hard disk >> image support now. I am wondering whether what I has >> learned from tracing code is true or false? I also found some possibility >> of optimization in block/vpc.c. Should I contact mentor >> assigned to this project in private or post the whole idea on the mailing >> list?? >> >> thanks very much >> >> Mitnick >> >> > > Hello Mitnick, > > asynchronous i/o is also missing in block/vpc.c. > > All newer block drivers support asynchronous reads and writes, > only some old drivers don't. > > So adding asynchronous i/o to at least some of the old drivers > would improve their usability. > > Look for "aio" in block/*.c to get a starting point. > > Regards > Stefan (W.) > >
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello Stefan Hello Mitnick, > > asynchronous i/o is also missing in block/vpc.c. > > All newer block drivers support asynchronous reads and writes, > only some old drivers don't. > > So adding asynchronous i/o to at least some of the old drivers > would improve their usability. > > Look for "aio" in block/*.c to get a starting point. > > Regards > Stefan (W.) > > I look for "aio" in block/*.c as a starting point of asynchronous i/o. And I found that there isn't any "aio" keywords in block/vmdk.c. block/vmdk.c is used as block driver for the VMDK format. Is it means that asynchronous i/o is also missing in VMDK format? thanks Mitnick
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello I have some question about asynchronous i/o in QEMU block driver: Why a file format with asynchronous i/o support(ex. qcow) doesn't need to register bdrv_read/bdrv_write which is registered in vhd file format?? Would qcow block driver also support synchronous i/o?? thanks a lot Mitnick 2011/4/2 Kevin Wolf > Am 01.04.2011 17:15, schrieb Lyu Mitnick: > > Hello Stefan > > > > Hello Mitnick, > > > > asynchronous i/o is also missing in block/vpc.c. > > > > All newer block drivers support asynchronous reads and writes, > > only some old drivers don't. > > > > So adding asynchronous i/o to at least some of the old drivers > > would improve their usability. > > > > Look for "aio" in block/*.c to get a starting point. > > > > Regards > > Stefan (W.) > > > > > > I look for "aio" in block/*.c as a starting point of asynchronous i/o. > > And I > > found that there isn't any "aio" keywords in block/vmdk.c. block/vmdk.c > > is used as block driver for the VMDK format. Is it means that > asynchronous > > i/o is also missing in VMDK format? > > Yes, the VMDK implementation is completely synchronous. > > Kevin >
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello Stefan, I have take a look at block.c. But I am a little confused about the meaning of synchronous/asynchronous i/o. I know the two concept in a operating system. However I am not sure whether it is analogous in virtual machine. 2011/4/2 Stefan Hajnoczi > On Fri, Apr 1, 2011 at 7:29 PM, Lyu Mitnick wrote: > > Hello > > I have some question about asynchronous i/o in QEMU block driver: Why a > file > > format with asynchronous i/o support(ex. qcow) doesn't need to register > > bdrv_read/bdrv_write which is registered in vhd file format?? Would qcow > > block driver > > also support synchronous i/o?? > > Take a look at block.c. There are synchronous I/O emulation (and > asynchronous I/O emulation) functions in case the block driver > provides only asynchronous (or synchronous, respectively) functions. > > One thing to mention about synchronous and asynchronous interfaces is > that block drivers which are synchronous really don't work well for > running VMs. They block execution until I/O completes (which can take > a long time) and therefore steal time from the guest (i.e. laggy, poor > I am wondering the meaning of execution block. It is for host host operating system or for guest operating system?? (ie, Could I issue an asynchronous i/o in guest operating system when the vhd file system image mounted) > responsiveness from the guest). Therefore synchronous block drivers > are useful for qemu-img convert but not running VMs. > > Stefan Mitnick
Re: [Qemu-devel] GSoC: Improved image format compatibility
Hello Stefan, 2011/4/3 Stefan Hajnoczi > On Sat, Apr 2, 2011 at 8:03 PM, Lyu Mitnick wrote: > > Hello Stefan, > > I have take a look at block.c. But I am a little confused about the > meaning > > of synchronous/asynchronous i/o. I know the two concept in a operating > > system. However I am not sure whether it is analogous in virtual > machine. > > You may want to read up on the QEMU threading model: > > http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-and.html > > (Over)simplifying a bit, only one host thread can be executing QEMU > code at any given time because QEMU is not thread-safe internally. If > the VM issues a disk read and QEMU uses a read(2) system call to > service it, then QEMU and the VM is blocked until the read(2) system > call completes. Therefore it is better to use asynchronous I/O in > QEMU and resume the VM. Once the read operation completes a callback > in QEMU is invoked and we can signal completion back to the VM. > > Also, in terms of the storage controller interfaces that QEMU emulates > (IDE, SCSI, virtio-blk) disk operations are queued or handed to the > hardware. The guest operating system expects to continue executing > while the disk operation is in progress. On completion the storage > controller raises an interrupt and the operating system will complete > the I/O. Again, this is an asynchronous (request/response) model > rather than a synchronous operation from the guest operating system > perspective. > > Look at hw/virtio-blk.c:virtio_blk_handle_output() for an example of > how disk emulation works in QEMU. > > For qemu-img it is more natural to use synchronous I/O because it is > just a sequential C program, not an event-driven program like QEMU. > > Stefan > I am writing my proposal now. I met a problem about describing "Adding Fixed hard disk image and Differencing hard disk image support into VHD format. This is a format with three sub-format . Is exist another format containing sub-format and I can take a look?? Thanks Mitnick
[Qemu-devel] GSoC - QCOW2 <-> QED image converter
Hello all, Looking at QEMU'w wiki I saw the "QCOW2 <- > QED image converter", that I am also interested to work as student and apply for GSoC 2011. I have study the specifications of the two images and have some idea about implementation. There is someone already working on this project?? I also want to apply for "Improved image format compatibility". Could I merge the two idea into one application or I should apply separately?? Thanks a lot Mitnick
Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter
Hello Stefan, Kevin I don't want to diversify my GSoC applications. I thought I should do my best of supporting fully VHD and add asynchronous io into block/vpc.c via coroutines. I noticed that there is "splitting hard disk images" feature in VHD specification. I have take a look of block/raw-win32.c and guess there isn't this feature in block/vpc.c. I am wondering whether what I learned is right?? 2011/4/5 Stefan Hajnoczi > On Mon, Apr 4, 2011 at 7:56 PM, Lyu Mitnick wrote: > > Hello all, > > Looking at QEMU'w wiki I saw the "QCOW2 <- > QED image converter", that I > > am > > also interested to work as student and apply for GSoC 2011. I have study > > the > > specifications of the two images and have some idea about > > implementation. There > > is someone already working on this project?? I also want to apply for > > "Improved > > image format compatibility". Could I merge the two idea into one > application > > or I should > > apply separately?? > > Other students have expressed their interest too, but that is normal > for GSoC project ideas. > > Please just note on your application that you'd be interested in doing > QCOW2<->QED, there's no need to do a separate application in this > case. The mentors are the same for both QCOW2<->QED and image format > updates. The area of these two projects is similar, and we select the > most talented students rather than the best application forms. I am > confident the selected student(s) would be capable of tackling either > project. > > If you want to diversify your GSoC applications to increase your > chance of getting a place, then I suggest applying at a different > organization in addition to QEMU.org. That way you are not subject to > the QEMU.org slot allocation. > > Stefan > Thanks a lot Mitnick
Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter
Hello Stefan, "splitting hard disk images" feature depends on win32 file system. I am wondering whether it is suitable to implement in raw-win32.c?? My idea is as follows: (1) adding an array to store file descriptor related in BDRVRawState (2) detect all splitted files in raw_open(). ie. consider files filename.vhd, filename.v01, filename.v02 ... . and construct the table to convert from sector_num to splitted file and offset (store in BDRVRawState, too). (3) use table constructed in step2 to read, write and flush (4) close all opened splitted files in raw_close() Would you mind to give some advice about the solution I take in this problem?? 2011/4/6 Stefan Hajnoczi > On Tue, Apr 5, 2011 at 7:03 PM, Lyu Mitnick wrote: > > Hello Stefan, Kevin > > I don't want to diversify my GSoC applications. I thought I should do my > > best of > > supporting fully VHD and add asynchronous io into block/vpc.c via > > coroutines. I > > noticed that there is "splitting hard disk images" feature in VHD > > specification. I > > have take a look of block/raw-win32.c and guess there isn't this feature > in > > block/vpc.c. > > I am wondering whether what I learned is right?? > > Yes, split images are not supported by block/vpc.c. > > Stefan > Thanks so much Mitnick
Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter
Hello Christoph, 2011/4/6 Christoph Hellwig > On Wed, Apr 06, 2011 at 05:15:29PM +0200, Kevin Wolf wrote: > > Am 06.04.2011 17:06, schrieb Christoph Hellwig: > > > On Wed, Apr 06, 2011 at 07:41:37AM +0100, Stefan Hajnoczi wrote: > > >> Yes, split images are not supported by block/vpc.c. > > > > > > I'm working on that feature for vmdk right now, which is quite > > > interesting as vmdk really is two different format both claiming > > > to be vmdk, of which one is simply a text file telling how other > > > vmdk images are glued together. > > > > Last time I checked the other one wasn't a single format either, but > > rather something like ten different subformats. > > The binary vmdk files have a few different revisions too, yes. > > > Anyway, if you're working on split VMDK images, I should probably stop > > advertising it as a GSoC project? > > I didn't know it was advertised, but there's indeed no need to duplicate > the > work. > > Would you mind to share your solution about this feature?? My idea is replace all bdrv_pread(), bdrv_pwrite_sync(), bdrv_pwrite() in block/vpc.c to bdrv_pread_split(), bdrv_pwrite_sync_split(), bdrv_pwrite_split() corresponding. bdrv_pread_split(), bdrv_pwrite_sync_split(), bdrv_pwrite_split() should deal with data splitted at different files via bdrv_pread(), bdrv_pwrite_sync(), bdrv_pwrite(), give an interface of sequential byte accessed. Is it suitable to solve this issue?? Thanks a lot Mitnick
[Qemu-devel] No scratch directory in qemu-iotests
Hello When I want to use qemu-iotests, some error occurred: $ git clone git:// git.kernel.org/pub/scm/linux/kernel/git/hch/qemu-iotests.git $ cd qemu-iotests $ ./check -h common.config: Error: $TEST_DIR (/home/mitnick/Desktop/GSoC2011/QEMU/qemu-iotests/scratch) is not a directory There is no error when I create directory scratch. I am wondering whether scratch should be add into qemu-iotests master tree?? Thanks Mitnick
[Qemu-devel] [PATCH] qemu-iotests: Fixed no scratch directory in qemu-iotests
This my first time to submit patch, please tell me if I have something wrong! Create scratch/ on first run. Signed-off-by: Mitnick Lyu --- common.config |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/common.config b/common.config index bdd0530..09923d9 100644 --- a/common.config +++ b/common.config @@ -102,6 +102,15 @@ export QEMU_IO="$QEMU_IO_PROG $QEMU_IO_OPTIONS" [ -f /etc/qemu-iotest.config ] && . /etc/qemu-iotest.config +if [ -e scratch -a ! -d scratch ]; then +echo "scratch exist and is not a directory" +exit 1 +fi + +if [ ! -e scratch ]; then +mkdir scratch +fi + if [ ! -e "$TEST_DIR" ]; then TEST_DIR=`pwd`/scratch fi -- 1.7.0.4
[Qemu-devel] Question about total_sectors in block/vpc.c
Hell all, I have take a look of block/vpc.c and meet a question in vpc_create(). At the line 550, the code is: total_sectors = options->value.n / 512; I am wondering whether the size between total_sectors * 512 and options->value.n would be discard. Thanks Mitnick
Re: [Qemu-devel] Question about total_sectors in block/vpc.c
Hello Stefan,
Is it your means:
There is an assumption that a block device cannot be addressed below 512
byte sectors.
A reasonable protection in block.c:bdrv_create() to check whether size is a
multiple of BDRV_SECTOR_SIZE.
Signed-off-by: Mitnick Lyu
---
block.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index f731c7a..a80ec49 100644
--- a/block.c
+++ b/block.c
@@ -239,6 +239,16 @@ int bdrv_create(BlockDriver *drv, const char* filename,
if (!drv->bdrv_create)
return -ENOTSUP;
+ while (options && options->name) {
+ if (!strcmp(options->name, "size")) {
+ if (options->value.n % 512 == 0)
+ break;
+ else
+ return -EINVAL;
+ }
+ options++;
+ }
+
return drv->bdrv_create(filename, options);
}
--
1.7.0.4
2011/4/10 Stefan Hajnoczi
> On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick wrote:
> > Hell all,
> > I have take a look of block/vpc.c and meet a question in vpc_create(). At
> > the line
> > 550, the code is:
> > total_sectors = options->value.n / 512;
> > I am wondering whether the size between total_sectors * 512
> > and options->value.n
> > would be discard.
>
> Yes, it rounds down. This reflects the assumption that a block device
> cannot be addressed below 512 byte sectors. Because of this block
> devices size must be a multiple of 512 bytes.
>
> I think a reasonable protection would be to have block.c:bdrv_create()
> fail if size is not a multiple of BDRV_SECTOR_SIZE. This way other
> image formats are protected too.
>
> Stefan
>
By the way, how could I know a submitted patch is accepted or not??
Thanks a lot
Mitnick
Re: [Qemu-devel] Question about total_sectors in block/vpc.c
Hello Christoph, Stefan I am wondering whether the problem occurred that value of BDRV_SECTOR_SIZE is a macro constant (defined at block.h). This problem could be fixed if we use variable instead of macro to implement BDRV_SECTOR_SIZE. Each block device may reassign the value if needed. Is it right?? Thanks a lot 2011/4/12 Christoph Hellwig > On Sat, Apr 09, 2011 at 09:05:41PM +0100, Stefan Hajnoczi wrote: > > On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick > wrote: > > > Hell all, > > > I have take a look of block/vpc.c and meet a question in > vpc_create().?At > > > the line > > > 550, the code is: > > > total_sectors = options->value.n / 512; > > > I am wondering whether the size between?total_sectors * 512 > > > and?options->value.n > > > would be discard. > > > > Yes, it rounds down. This reflects the assumption that a block device > > cannot be addressed below 512 byte sectors. Because of this block > > devices size must be a multiple of 512 bytes. > > > > I think a reasonable protection would be to have block.c:bdrv_create() > > fail if size is not a multiple of BDRV_SECTOR_SIZE. This way other > > image formats are protected too. > > There are block devices that aren't alignment to 512 bytes. Audio CDROMs > are > the most prominent example, or AS/400 disks. I don't think these matter > for > emulation, but if we'd ever implement DIF/DIX emulation inside qemu we'd > have to store the protection information somewhere. It still wouldn't > work with existing disk format, so adding the above check into the formats > bdrv_create routines sounds fine, but doing it in the core block code > might not be an overly smart idea. > > Mitnick
[Qemu-devel] Question about maximum disk size of a dynamic hard disk
Hello Kevin, Stefan and all There is a sentence "The maximum size of a dynamic hard disk is 2040 GB. The actual size is restricted by the underlying disk hardware protocol. For example, ATA hard disks have a 127-GB limit" in VHD specification. This limitation infected the algorithm of block/vpc.c:calculate_geometry(). However, SATA disk is used to replace traditional IDE disk now. I am wondering whether is possible to support that VHD is bigger than 127-GB(SATA disk underlying)?? Thanks Mitnick
Re: [Qemu-devel] Question about total_sectors in block/vpc.c
Hello Stefan,
I have a question about get_option_parameter(). I am wondering whether
get_option_parameter is suitable to use instead of doing the search by
myself
in the case like following:
/* Read out options */
while (options && options->name) {
if (!strcmp(options->name, BLOCK_OPT_SIZE)) {
// do something
} else if (!strcmp(options->name, BLOCK_OPT_CLUSTER_SIZE)) {
// do something
}
options++;
}
Thanks
2011/4/11 Stefan Hajnoczi
> On Sun, Apr 10, 2011 at 05:02:20PM +0800, Lyu Mitnick wrote:
> > diff --git a/block.c b/block.c
> > index f731c7a..a80ec49 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -239,6 +239,16 @@ int bdrv_create(BlockDriver *drv, const char*
> filename,
> > if (!drv->bdrv_create)
> > return -ENOTSUP;
> >
> > + while (options && options->name) {
> > + if (!strcmp(options->name, "size")) {
> > + if (options->value.n % 512 == 0)
> > + break;
> > + else
> > + return -EINVAL;
> > + }
> > + options++;
> > + }
>
> Please use BDRV_SECTOR_SIZE instead of hardcoding 512.
>
> get_option_parameter() does the search for you, please use it instead of
> duplicating the loop.
>
> Please see the CODING_STYLE and HACKING files, new code should follow it:
> * Indentation is 4 spaces
> * Always use {} even for if/else with single-statement bodies
>
> Stefan
>
Mitnick
Re: [Qemu-devel] Question about total_sectors in block/vpc.c
Hello Kevin,
2011/4/14 Kevin Wolf
> Am 13.04.2011 22:59, schrieb Lyu Mitnick:
> > Hello Stefan,
> >
> > I have a question about get_option_parameter(). I am wondering whether
> > get_option_parameter is suitable to use instead of doing the search by
> > myself
> > in the case like following:
> >
> > /* Read out options */
> > while (options && options->name) {
> > if (!strcmp(options->name, BLOCK_OPT_SIZE)) {
> > // do something
> > } else if (!strcmp(options->name, BLOCK_OPT_CLUSTER_SIZE)) {
> >// do something
> > }
> > options++;
> > }
>
> Yes, I think it is, though you need to check whether the option has been
> set in order to allow use default values.
>
> Kevin
>
I have no idea about the mean of "check whether the option has been set in
order to allow use default values" , would you mind to give me an example
about
it??
So as the example above. I am wondering whether the code should be
rewritten
as:
/* Read out options */
if(get_option_parameter(options, BLOCK_OPT_SIZE)) {
// do something
}
if (get_option_parameter(options, BLOCK_OPT_CLUSTER_SIZE)) {
// do something
}
in QEMU??
Thanks
Mitnick
[Qemu-devel] Question about vpc 004 testcase of qemu-iotests
Hello all, I use qemu-iotests to test vpc part of master tree. An error occurred when I type ./check -vpc. Error message is as follows: 004 4s ... - output mismatch (see 004.out.bad) --- 004.out 2011-04-10 15:43:21.819400771 +0800 +++ 004.out.bad 2011-04-17 10:45:00.642745274 +0800 @@ -9,7 +9,8 @@ write failed: Input/output error write at image boundary -write failed: Input/output error +wrote 4096/4096 bytes at offset 134217728 +4 KiB, 1 ops; 0. sec (28.678 KiB/sec and 7.1694 ops/sec) write past image boundary write failed: Input/output error @@ -28,7 +29,8 @@ read failed: Input/output error read at image boundary -read failed: Input/output error +read 4096/4096 bytes at offset 134217728 +4 KiB, 1 ops; 0. sec (62.004 MiB/sec and 15873.0159 ops/sec) read past image boundary read failed: Input/output error I am wondering whether it is a bug of block/vpc.c?? Thanks Mitnick
[Qemu-devel] Question about debugging binary translator (TCG beckend) in system mode
Hello all, I have written my own TCG code generator (translate TCG to i386). It works well in user mode (pass every benchmark). However, there is something error in system mode: Host - x86-64, Configuration - --target-list=i386-softmmu --enable-debug --disable-kvm | minix2.04 | small-ffs (NetBSD) single step| correct | correct non-single step | correct | init panic(restart) (I have comment tb_add_jump of cpu-exec:cpu_exec to disable block chaining) I dump the exec but there is so much logs to debug. I am wondering to know how TCG codegen developer debug during development ?? thanks a lot Mitnick
