Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
On 2012年06月12日 03:12, Paolo Bonzini wrote: Il 11/06/2012 17:37, Jeff Cody ha scritto: It sounds like Zhi Hui is working on live block commit patches, and Supriya is working on the bdrv_reopen() portion - I don't want to duplicate any effort, but if there is anything I can do to help with either of those areas, just let me know. Is Zhi Hui going to move forward with the floppy patches? Paolo Yes, I am continue to move forward with the floppy patches. But I am also very interesting in block commit, so I want to do it. Thank you very much!
Re: [Qemu-devel] CoW image commit+shrink(= make_empty) support
On 2012年06月11日 23:37, Jeff Cody wrote: On 06/11/2012 10:24 AM, Stefan Hajnoczi wrote: On Mon, Jun 11, 2012 at 1:50 PM, Kevin Wolf wrote: Am 11.06.2012 14:09, schrieb Stefan Hajnoczi: On Fri, Jun 8, 2012 at 6:46 PM, Jeff Cody wrote: On 06/08/2012 12:11 PM, Kevin Wolf wrote: Am 08.06.2012 16:32, schrieb Jeff Cody: On 06/08/2012 09:53 AM, Stefan Hajnoczi wrote: On Fri, Jun 8, 2012 at 2:19 PM, Jeff Cody wrote: On 06/08/2012 08:42 AM, Stefan Hajnoczi wrote: Let's figure out how to specify block-commit so we're all happy, that way we can avoid duplicating work. Any comments on my notes above? I think we are almost completely on the same page - devil is in the details, of course (for instance, on how to convert the destination base from r/o to r/w). Great. The atomic r/o -> r/w transition and the commit coroutine can be implemented on in parallel. Are you happy to implement the atomic r/o -> r/w transition since you wrote bdrv_append()? Then Zhi Hui can assume that part already works and focus on implementing the commit coroutine in the meantime. I'm just suggesting a way to split up the work, please let me know if you think this is good. I am happy to do it that way. I'll shift my focus to the atomic image reopen in r/w mode. I'll go ahead and post my diagrams and other info for block-commit on the wiki, because I don't think it conflicts with we discussed above (although I will modify my diagrams to not show commit from the top-level image). Of course, feel free to change it as necessary. I may have mentioned it before, but just in case: I think Supriya's bdrv_reopen() patches are a good starting point. I don't know why they were never completed, but I think we all agreed on the general design, so it should be possible to pick that up. Though if you have already started with your own work on it, Jeff, I expect that it won't be much different because it's basically the same transactional approach that you know and that we already used for group snapshots. I will definitely use parts of Supriya's as it makes sense - what I started work on is similar to bdrv_append() and the current transaction approach, so there will be plenty in common to reuse, even with some differences. I have CCed Supriya who has been working on the reopen patch series. She is close to posting a new version. It's just a bit disappointing that it takes several months between each two versions of the patch series. We'd like to have this in qemu 1.2, not only in qemu 1.14. I can understand if someone can't find the time, but then allow at least someone else to pick it up. Hey, don't shoot the messenger :). I just wanted add Supriya to CC so she can join the discussion and see how much overlap there is with what she's doing. We all contribute to QEMU from different angles and with different priorities. If there is a time critical dependency on the reopen code then discuss it here and the result will be that someone officially drives the feature on. I am more than happy to take the previous reopen() patches, and drive those forward, and also do whatever else is needed for live block commit. It sounds like Zhi Hui is working on live block commit patches, and Supriya is working on the bdrv_reopen() portion - I don't want to duplicate any effort, but if there is anything I can do to help with either of those areas, just let me know. Thanks, Jeff Jeff please go ahead with block-commit, I am finishing up my fdc async conversion patch series first. I will reply when I'm ready to work on block-commit. Thank you very much!
[Qemu-devel] question about irq update
In the code of libqtest.c have a function :
bool qtest_get_irq(QTestState *s, int num)
{
/* dummy operation in order to make sure irq is up to date */
qtest_inb(s, 0);
return s->irq_level[num];
}
but I don't know how it can make the irq up to date
and why we will read from the address of 0 ?
can anybody explain for me?
Thank you very much!
Re: [Qemu-devel] question about irq update
On 2012年06月15日 17:04, Paolo Bonzini wrote: It just forces libqtest to read any pending events. Ok, Thank you very much! :)
Re: [Qemu-devel] [PATCH 01/36] ds1225y: Use stdio instead of QEMUFile
On 10/11/2011 06:00 PM, Juan Quintela wrote:
QEMUFile * is only intended for migration nowadays. Using it for
anything else just adds pain and a layer of buffers for no good
reason.
Signed-off-by: Juan Quintela
---
hw/ds1225y.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/hw/ds1225y.c b/hw/ds1225y.c
index 9875c44..6852a61 100644
--- a/hw/ds1225y.c
+++ b/hw/ds1225y.c
@@ -29,7 +29,7 @@ typedef struct {
DeviceState qdev;
uint32_t chip_size;
char *filename;
-QEMUFile *file;
+FILE *file;
uint8_t *contents;
} NvRamState;
@@ -70,9 +70,9 @@ static void nvram_writeb (void *opaque, target_phys_addr_t
addr, uint32_t val)
s->contents[addr] = val;
if (s->file) {
-qemu_fseek(s->file, addr, SEEK_SET);
-qemu_put_byte(s->file, (int)val);
-qemu_fflush(s->file);
+fseek(s->file, addr, SEEK_SET);
+fputc(val, s->file);
+fflush(s->file);
}
}
@@ -108,15 +108,17 @@ static int nvram_post_load(void *opaque, int version_id)
/* Close file, as filename may has changed in load/store process */
if (s->file) {
-qemu_fclose(s->file);
+fclose(s->file);
}
/* Write back nvram contents */
-s->file = qemu_fopen(s->filename, "wb");
+s->file = fopen(s->filename, "wb");
if (s->file) {
/* Write back contents, as 'wb' mode cleaned the file */
-qemu_put_buffer(s->file, s->contents, s->chip_size);
-qemu_fflush(s->file);
+if (fwrite(s->contents, s->chip_size, 1, s->file) != 1) {
+printf("nvram_post_load: short write\n");
+}
+fflush(s->file);
}
return 0;
@@ -143,7 +145,7 @@ typedef struct {
static int nvram_sysbus_initfn(SysBusDevice *dev)
{
NvRamState *s =&FROM_SYSBUS(SysBusNvRamState, dev)->nvram;
-QEMUFile *file;
+FILE *file;
int s_io;
s->contents = g_malloc0(s->chip_size);
@@ -153,11 +155,13 @@ static int nvram_sysbus_initfn(SysBusDevice *dev)
sysbus_init_mmio(dev, s->chip_size, s_io);
/* Read current file */
-file = qemu_fopen(s->filename, "rb");
+file = fopen(s->filename, "rb");
if (file) {
/* Read nvram contents */
-qemu_get_buffer(file, s->contents, s->chip_size);
-qemu_fclose(file);
+if (fread(s->contents, s->chip_size, 1, file) != 1) {
+printf("nvram_sysbus_initfn: short read\n");
+}
+fclose(file);
}
nvram_post_load(s, 0);
Tested-by: Zhi Hui Li
[Qemu-devel] Help me about the FDC
I am read the code of fdc.c , I feel it was difficult to understand. Can somebody give me some help: thank you very much! 1: explain the difference between : type_register_static(&isa_fdc_info); type_register_static(&sysbus_fdc_info); type_register_static(&sun4m_fdc_info); 2: explain the struct of FDCtrl; 3: or give me some introduce of FDC.
[Qemu-devel] Thank you very much！
[Qemu-devel] [PATCH] net/socket.c : fix memory leak
Signed-off-by: Li Zhi Hui
---
net/socket.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index e9ef128..0f09164 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -409,6 +409,7 @@ static int net_socket_listen_init(VLANState *vlan,
fd = qemu_socket(PF_INET, SOCK_STREAM, 0);
if (fd < 0) {
perror("socket");
+g_free(s);
return -1;
}
socket_set_nonblock(fd);
@@ -420,11 +421,13 @@ static int net_socket_listen_init(VLANState *vlan,
ret = bind(fd, (struct sockaddr *)&saddr, sizeof(saddr));
if (ret < 0) {
perror("bind");
+g_free(s);
return -1;
}
ret = listen(fd, 0);
if (ret < 0) {
perror("listen");
+g_free(s);
return -1;
}
s->vlan = vlan;
--
1.7.4.1
[Qemu-devel] [PATCH] os-win32.c : fix memory leak
string is allocated by g_malloc, will not be used after putenv, should be free before return. Signed-off-by: Li Zhi Hui --- os-win32.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/os-win32.c b/os-win32.c index 8ad5fa1..e6e9143 100644 --- a/os-win32.c +++ b/os-win32.c @@ -44,6 +44,7 @@ int setenv(const char *name, const char *value, int overwrite) char *string = g_malloc(length); snprintf(string, length, "%s=%s", name, value); result = putenv(string); +g_free(string); } return result; } -- 1.7.4.1
[Qemu-devel] can anyone help me ?
when I gdb the ./x86_64-softmmu/qemu-system-x86_64 It always receive the signal, "Program received signal SIG38, Real-time event 38.", can you tell the reason and how to solve it ? Thank you very much!
Re: [Qemu-devel] can anyone help me ?
I do not receive this signal. But I think you can try > handle SIG38 noprint pass > to ignore this signal. > > thank you, I found the problom, just like you say, enter this command will solve it. "handle SIG38 pass noprint nonstop" the problem maybe is my libthread_db.* don't involve the debug message. alse thank you very much!
Re: [Qemu-devel] [PATCH] hw/smbus_eeprom.c : fix memory leak
On 2011年12月02日 11:47, Mark Wu wrote: On 12/02/2011 11:23 AM, Li Zhi Hui wrote: Signed-off-by: Li Zhi Hui --- hw/smbus_eeprom.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/smbus_eeprom.c b/hw/smbus_eeprom.c index 5d080ab..d66fbbc 100644 --- a/hw/smbus_eeprom.c +++ b/hw/smbus_eeprom.c @@ -142,4 +142,5 @@ void smbus_eeprom_init(i2c_bus *smbus, int nb_eeprom, qdev_prop_set_ptr(eeprom, "data", eeprom_buf + (i * 256)); qdev_init_nofail(eeprom); } + g_free(eeprom_buf); } The memory pointed by eeprom_buf is used as 'data' buf of 8 SMBusEEPROMDevice after initialization. And it calls qdev_init_nofail, which will exit on failure. it should be ok to leave it there. Anyway, you shouldn't free it in the initialization. Mark. I'm afraid I was too fast when I sent a patch with memory leak, and don't look it carefully , It was a pointer to a pointer. I agree with Mark Wu.
Re: [Qemu-devel] [PATCH] qemu-nbd.c : fix memory leak
Thank you very much!
[Qemu-devel] About the snapshot
1) : for example: BDRVQcowState *s = bs->opaque; s->snapshots s->nb_snapshots 1:use the command: qemu-img snapshot ./test.qcow2 -c aa the memory of the s->snapshot don't free, if the s->nb_snapshots is large, Does it have some problems. 2: use the command: qemu-system-x86_64 ./test.qcow2 -snapshot when the program ends, Does it need to free the s->snapshots ? 2): in the function of qcow2_update_snapshot_refcount it has some " goto fail "; if the function runs some times, then something makes it goto fail, I am not sure whether it will make the refcount incorrect.
Re: [Qemu-devel] About the snapshot
On 2011年12月06日 17:40, Stefan Hajnoczi wrote: On Tue, Dec 6, 2011 at 9:07 AM, Zhi Hui Li wrote: 1) : for example: BDRVQcowState *s = bs->opaque; s->snapshots s->nb_snapshots 1:use the command: qemu-img snapshot ./test.qcow2 -c aa the memory of the s->snapshot don't free, if the s->nb_snapshots is large, Does it have some problems. 2: use the command: qemu-system-x86_64 ./test.qcow2 -snapshot when the program ends, Does it need to free the s->snapshots ? These two commands are unrelated. QEMU uses the term "snapshot" for several different features: 1. qemu-img snapshot refers to "internal snapshots" that are contained within qcow2 image files. The savevm/loadvm/delvm monitor commands operate on internal snapshots. 2. qemu -snapshot refers to a temporary qcow2 image file created to buffer any data that the guest writes. When QEMU exits your disk image is not modified and the temporary qcow2 file is deleted. You can also apply the buffer to the disk image using the "commit" monitor command. yes, I understand what you say, but the qemu-img and savevm both call the function of qcow2_snapshot_create, when I use the command qemu-img snapshot ./test.qcow2 -c aa, but the memory of the s->snapshot don't free. 2): in the function of qcow2_update_snapshot_refcount it has some " goto fail "; if the function runs some times, then something makes it goto fail, I am not sure whether it will make the refcount incorrect. When an error occurs its possible that refcount leaks are introduced (the refcount was increment but will never be used), but we should never decrement a reference that is still in use. Please be more specific about the problem so that Kevin or I can take a look. Stefan Ok, I got it. thank you very much !
Re: [Qemu-devel] About the snapshot
2011/12/6 Stefan Hajnoczi > On Tue, Dec 6, 2011 at 10:01 AM, Zhi Hui Li > wrote: > > On 2011年12月06日 17:40, Stefan Hajnoczi wrote: > >> > >> On Tue, Dec 6, 2011 at 9:07 AM, Zhi Hui Li > >> wrote: > >>> > >>> > >>> 1) : > >>> > >>> for example: > >>> > >>> BDRVQcowState *s = bs->opaque; > >>> > >>> s->snapshots > >>> s->nb_snapshots > >>> > >>> > >>> 1:use the command: qemu-img snapshot ./test.qcow2 -c aa > >>> the memory of the s->snapshot don't free, > >>> if the s->nb_snapshots is large, Does it have some problems. > >>> > >>> 2: use the command: qemu-system-x86_64 ./test.qcow2 -snapshot > >>> when the program ends, Does it need to free the s->snapshots ? > >> > Okay, I think you're saying that in #1 s->snapshots is leaked because > qcow2_free_snapshots() is not being called from qcow2_close(). > > Do you want to send a patch to fix this? > Ok, I will send a patch tomorrow. But I think in the #2 it also need to call qcow2_free_snapshots() , if you have called several times savevm, the s->snapshots will very large, when the process end, it also need to free. Thank you very much for your feedback ! > > Stefan > >
[Qemu-devel] some questions about g_malloc in qemu
I am not sure whether it is need to check the return of g_malloc in qemu ? Thank you very much !
Re: [Qemu-devel] some questions about g_malloc in qemu
On 2011年12月15日 17:36, Stefan Hajnoczi wrote: On Thu, Dec 15, 2011 at 04:28:28PM +0800, 陳韋任 wrote: I found this in HACKING: Please note that NULL check for the g_malloc result is redundant and that g_malloc() call with zero size is not allowed. So we have: 1. You should not request 0 bytes from g_malloc(). 2. g_malloc() does not return NULL (if you follow rule #1). There is no need to check for NULL return. Stefan Maybe there is insufficient memory, the return is error, Do we need to check the return ? Thank you very much for your feedback!
[Qemu-devel] Virtual FAT disk images error, can somebody help me , thank you !
when I use the command : 1: mkdir /my_directory 2: qemu linux.img -fda fat:floppy:/my_directory when I write to the floppy(just "mkdir test.dir" in the floppy), the error occur: "FLOPPY ERROR: fdctrl_transfer_handler: writing sector 1" and nothing is written to the /my_directory. I don't know why? can you help me, thank you very much!
[Qemu-devel] How many floppy can a computer install ? Thank you very much!
Re: [Qemu-devel] [PATCH v3] Replace bdrv_* to bdrv_aio_* functions in DMA mode in fdc.c.
I think what you say up is right, I will correct them, thank you very much! +bdrv_aio_readv(cur_drv->bs, fd_sector(cur_drv), +&fdctrl->qiov, fdc_sector_num, fdctrl_read_DMA_cb, opaque_cb); +return dma_len; Should be return 0 since we haven't completed I/O yet. Stefan I think the return value is not used not, so no matter what is returned it not necessary. if set the dma_len = 0, when call void DMA_set_return(int nret) function will return the real value; :)
Re: [Qemu-devel] [PATCH v2] Replace bdrv_* to bdrv_aio_* functions in pio mode in fdc.c.
On 2012年04月02日 20:07, Stefan Hajnoczi wrote: On Sat, Mar 31, 2012 at 09:15:10PM +0800, Li Zhi Hui wrote: Replace bdrv_* to bdrv_aio_* functions in pio mode in fdc.c. Signed-off-by: Li Zhi Hui --- hw/fdc.c | 123 +- 1 files changed, 89 insertions(+), 34 deletions(-) How can I test this patch? Stefan sorry, I don't find a good way to test it directly. but I have read the datasheet of floppy, I modify it according to the datasheet.
[Qemu-devel] A error when gdb the newest branch, can you help me? Thank you very much!
when I git pull to the newest branch, then gdb ./x86_64-softmmu/qemu-system-x86_64 set args, then run the gdb, but have the error: Warning: Cannot insert breakpoint -1. Error accessing memory address 0x2b6688: Input/output error. I don't know why, can you have me? Thank you very much !
Re: [Qemu-devel] A error when gdb the newest branch, can you help me? Thank you very much!
On 2012年04月16日 17:50, Stefan Hajnoczi wrote: On Mon, Apr 16, 2012 at 3:58 AM, Zhi Hui Li wrote: when I git pull to the newest branch, then gdb ./x86_64-softmmu/qemu-system-x86_64 set args, then run the gdb, but have the error: Warning: Cannot insert breakpoint -1. Error accessing memory address 0x2b6688: Input/output error. I tried to reproduce this but it works on my machine with gdb 7.4-debian. Is your system up-to-date? Do you have any special security activated (SELinux, grsec, etc) which might prevent ptrace? Stefan Thank you very much for your feedback, I found the reason: when I git pull to the newest branch then use gdb 7.2, the error will happen, when I update gdb to 7.3, That is ok. But I don't know the reason. Maybe the newest branch brings something which don't compatible with gdb.
Re: [Qemu-devel] [PATCH] add function DMA_set_return and delete bh_schedule in dma.c
On 2012年04月17日 16:46, Paolo Bonzini wrote:
Il 16/04/2012 14:14, Stefan Hajnoczi ha scritto:
Why are you removing the rearm behavior? I'm pretty sure other ISA
devices rely on this otherwise the code wouldn't exist.
Li is correct in that the code can be simplified a lot, but indeed his
axe went a bit too far. :)
With the exception of the floppy all other DMA devices do not reenter
DMA_run, and do not need the idle bottom half hack because DMA is done
once per interrupt. And now that the floppy is asynchronous it doesn't
need the idle bottom half hack, either.
So DMA_run can call channel_run from a while loop like this:
while ((0 == (d->mask& mask))&& (0 != (d->status& (mask<< 4 {
// pseudo-code, channel_running and channel_is_asynchronous
// would be fields in dma_regs
if (channel_running[ichan]) {
assert(channel_is_asynchronous[ichan]);
break;
}
channel_running[ichan]++;
channel_run (icont, ichan);
// channel_is_asynchronous would be set by a new function
// DMA_register_channel_async.
if (channel_is_asynchronous[ichan]) {
break;
}
channel_running[ichan]--;
}
and DMA_set_return needs to do a tail call to "complete" the while loop:
assert(channel_is_asynchronous[ichan]);
assert(channel_running[ichan] == 1);
channel_running[ichan]--;
if ((0 == (d->mask& mask))&& (0 != (d->status& (mask<< 4 {
channel_run (icont, ichan);
}
Paolo
Thank you very much for giving me suggestions, I have tried the method,
it works well. But I also have another idea, I modify fdc.c by adding a
flag to avoid re-enter, I have tested it. I will send a patch later. If
you have any comments, please give me your opinion. thanks.
[Qemu-devel] backing_file Path
when I trace the code of qemu-img.c， I found in the image file, the backing_file use the relative path, I think Maybe it has some problems. for example: 1: qemu-img create -o backing_file=../ aa.img 5G 2: qemu-system-x86_64 aa.img if you change aa.img's the path, the exec is wrong,it can't find the backing_file path, because the backing_file use the relative path, Could we change the relative path to the absolute path?
[Qemu-devel] I have some questions in block , can anyone help me, thank you!
questions: 1) In qcow2.c, in function: qcow2_co_readv In qcow2.h, in struct BDRVQcowState I want to know the relations between sector_num in function qcow2_co_readv and cluster_sectors in struct BDRVQcowState ? 2) In qcow2.c, in function; qcow2_co_writev at line 547: index_in_cluster = sector_num & (s->cluster_sectors - 1); How to understand it ? 3) In qcow2.c, in the function : qcow2_co_readv and qcow2_co_writev I want to know the least unit that it was read by the function. for example: BDRVQcowState s; Is s->cluster_size or 512 ? Thank you very much ! Best regards!
Re: [Qemu-devel] I have some questions in block , can anyone help me, thank you!
On 2011年11月14日 18:00, Stefan Hajnoczi wrote: On Mon, Nov 14, 2011 at 01:47:41PM +0800, Zhi Hui Li wrote: 1) In qcow2.c, in function: qcow2_co_readv In qcow2.h, in struct BDRVQcowState I want to know the relations between sector_num in function qcow2_co_readv and cluster_sectors in struct BDRVQcowState ? sector_num is the starting offset of the I/O request. For example, sector_num=10 means that the read begins at 10 * 512 = 5120 bytes. cluster_sectors is the number of sectors in a qcow2 cluster. (The qcow2 format manages space in "clusters" instead of sectors. They are typically many sectors large, e.g. 128.) 2) In qcow2.c, in function; qcow2_co_writev at line 547: index_in_cluster = sector_num& (s->cluster_sectors - 1); How to understand it ? cluster_sectors is a power of 2, e.g. 1024, 2048, 4096, and so on. So this expression is the same as: index_in_cluster = sector_num % cluster_sectors It calculates the offset from the start of the cluster. For example: sector_num = 130 cluster_sectors = 128 cluster = sector_num / cluster_sectors = 1 index_in_cluster = sector_num % cluster_sectors = 2 We can get back to the original sector_num value like this: sector_num = cluster * cluster_sectors + index_in_cluster = 1 * 128 + 2 = 130 So this is about managing space in "clusters". It's similar to how memory is managed in pages instead of bytes by the memory management unit. 3) In qcow2.c, in the function : qcow2_co_readv and qcow2_co_writev I want to know the least unit that it was read by the function. for example: BDRVQcowState s; Is s->cluster_size or 512 ? The block layer minimum I/O size is BDRV_SECTOR_SIZE. For convenience there is the bdrv_pread()/bdrv_pwrite() interface which allows byte-granularity access but uses bounce buffers underneath. s->cluster_size is the number of bytes per cluster. A cluster is typically 64 KB but the value can be set in the image file. Qcow2 internally manages space in cluster but the I/O granularity is BDRV_SECTOR_SIZE (512). Stefan Thank you very much!
Re: [Qemu-devel] [PATCH 1/2 v5-test] add function DMA_set_return and DMA_set_channel_async in dma.c
+
+void DMA_set_return(int nret, int nchan)
+{
+struct dma_regs *r;
+struct dma_cont *d;
+int icont, ichan;
+
+icont = nchan> 3;
+ichan = nchan& 3;
+d = dma_controllers;
+r =&d[icont].regs[ichan];
+r->now[COUNT] = nret;
+assert(r->channel_is_asynchronous);
+assert(r->channel_running);
Thanks, this is very much like what I had in mind, except that here I
would have called DMA_run. Also you can then remove the bottom half
(and rearm logic) completely.
If calling DMA_run is not working, perhaps it is because you didn't
remove the bottom half.
You have written to me :
assert(channel_is_asynchronous[ichan]);
assert(channel_running[ichan] == 1);
channel_running[ichan]--;
if ((0 == (d->mask & mask)) && (0 != (d->status & (mask << 4 {
channel_run (icont, ichan);
}
If I add the code :
if ((0 == (d->mask & mask)) && (0 != (d->status & (mask << 4 {
channel_run (icont, ichan);
}
Because function DMA_set_return is called in fdctrl_read_DMA_cb and
fdctrl_write_DMA_cb, the fdctrl_stop_transfer will release the channel,
but fdctrl_stop_transfer is after the DMA_set_return, so the channel_run
will run again, so here I delete the above code.
I would hope that you can also change the "if (running) goto out;" to an
"assert(!running)", but I'm not so sure.
sorry, here I don't understand well,or you can explain in detail. :)
Thank you very much for your feedback! :)
[Qemu-devel] compile problem
Ater I git pull to the newest version, I make qemu, the error happen: CCx86_64-softmmu/vga.o CCx86_64-softmmu/memory.o CCx86_64-softmmu/savevm.o CCx86_64-softmmu/xen-all.o cc1: warnings being treated as errors /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ make[1]: *** [xen-all.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I don't know why, can anyone help me ? thank you very much !
Re: [Qemu-devel] compile problem
On 2012年04月23日 16:21, Paolo Bonzini wrote: Il 23/04/2012 10:13, Zhi Hui Li ha scritto: Ater I git pull to the newest version, I make qemu, the error happen: CCx86_64-softmmu/vga.o CCx86_64-softmmu/memory.o CCx86_64-softmmu/savevm.o CCx86_64-softmmu/xen-all.o cc1: warnings being treated as errors /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c: In function ‘xen_hvm_inject_msi’: /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: implicit declaration of function ‘xc_hvm_inject_msi’ /home/mm/code-new/qemu-2012-3-19/test-new/qemu/xen-all.c:132:5: error: nested extern declaration of ‘xc_hvm_inject_msi’ make[1]: *** [xen-all.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I don't know why, can anyone help me ? thank you very much ! A pull request has been sent for this. In the meanwhile, if you don't use Xen you can just comment out the offending line. Paolo Thank you very much! :)
Re: [Qemu-devel] [PATCH 2/3 v6] Replace bdrv_* to bdrv_aio_* functions in DMA mode in fdc.c
On 2012年05月15日 17:27, Paolo Bonzini wrote:
Il 15/05/2012 11:17, Li Zhi Hui ha scritto:
Signed-off-by: Paolo Bonzini
Signed-off-by: Li Zhi Hui
---
hw/fdc.c | 313 +
1 files changed, 210 insertions(+), 103 deletions(-)
To reviewers, this is obviously missing migration support. :)
Yes, you are right.
I am sorry that I am a newer, I don't know more about migration, so I
want to send some simple code first .
It is also missing a good commit message. It should say that the
support in the existing code for scan commands has a lot of "weirdness",
for example:
-if ((ret< 0&& fdctrl->data_dir == FD_DIR_SCANL) ||
-(ret> 0&& fdctrl->data_dir == FD_DIR_SCANH)) {
-status2 = 0x00;
-goto end_transfer;
...
- end_transfer:
-len = fdctrl->data_pos - start_pos;
-FLOPPY_DPRINTF("end transfer %d %d %d\n",
- fdctrl->data_pos, len, fdctrl->data_len);
-if (fdctrl->data_dir == FD_DIR_SCANE ||
-fdctrl->data_dir == FD_DIR_SCANL ||
-fdctrl->data_dir == FD_DIR_SCANH)
-status2 = FD_SR2_SEH;
which blindly overwrites status2. Hence the new code was not written
based on it. However, the new code is untested as far as I know.
Ok, I will add the commit message.
+if (fdctrl->data_dir == FD_DIR_SCANE ||
+fdctrl->data_dir == FD_DIR_SCANL ||
+fdctrl->data_dir == FD_DIR_SCANH) {
+fdctrl->dma_status2 = FD_SR2_SEH;
+}
This should be FD_SR2_SNS (Spec for the FDC is at
http://www.cepece.info/amstrad/docs/i8272/8272sp.htm: "If the conditions
for scan are not met between the the starting sector (as specified by R)
and the last sector on the cylinder (EOT), then the FDC sets the SN
(Scan Not Satisfied) flag of Status Register 2 to a 1 (high), and
terminates the Scan Command").
ok.
Thank you very much for your feedback. :)
[Qemu-devel] A error abou t gtester-report, can anyone help me, thank you !
When I use gtest.
Compiler did not have a problem, the use of gtester implementation and
generate xml file testlog also no problem, but in the use of
gterster-report, the output is as follows:
gtester-report test.log > test-report.html
Traceback (most recent call last):
File "/usr/bin/gtester-report", line 492, in
main()
File "/usr/bin/gtester-report", line 486, in main
HTMLReportWriter(rr.get_info(), rr.binary_list()).printout()
File "/usr/bin/gtester-report", line 350, in printout
self.handle_info ()
File "/usr/bin/gtester-report", line 244, in handle_info
self.oprint ('Package: %(package)s, version:
%(version)s\n' % self.info)
KeyError: 'package'
li@mm:~/ceshi/g_test$ gtester-report test.log > test-report.html
Traceback (most recent call last):
File "/usr/bin/gtester-report", line 492, in
main()
File "/usr/bin/gtester-report", line 486, in main
HTMLReportWriter(rr.get_info(), rr.binary_list()).printout()
File "/usr/bin/gtester-report", line 350, in printout
self.handle_info ()
File "/usr/bin/gtester-report", line 244, in handle_info
self.oprint ('Package: %(package)s, version:
%(version)s\n' % self.info)
KeyError: 'package'
I don't know why the error " KeyError: 'package' " appear. can anybody
help me ?
Thank you very much!
Re: [Qemu-devel] [PATCH 2/3 v6] Replace bdrv_* to bdrv_aio_* functions in DMA mode in fdc.c
On 2012年05月15日 17:38, Paolo Bonzini wrote: Il 15/05/2012 11:33, Kevin Wolf ha scritto: which blindly overwrites status2. Hence the new code was not written based on it. However, the new code is untested as far as I know. In the thread of an earlier version of this series, I said that a qtest for floppy is required. This only confirms it. The problem with writing a qtest is that the spec is incredibly complex and obscure. It's probably even better to rip out code that cannot be tested properly, so you don't have to test it at all... (Mostly tongue-in-cheek of course. A qtest for basic read/write in PIO and DMA modes is indeed a very good idea). Paolo Yes , I think maybe Paolo is right. Because the spec is incredibly complex and obscure and I am newer. To write the whole code's qtest beyond my ability. I am afraid I can't finish it. so I want only do a qtest about basic read/write in PIO and DMA modes. I don't know whether it is OK. (I don't know whether we can use qtest to replace the real test, especially on PIO mode 's test.) Thank you very much.
