coremu-list-devel Mailing List for coremu-mailing-list (Page 4)
Brought to you by:
cyfdecyf
Menu
▾
▴
coremu-list-devel — coremu devel mailing list
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
(21) |
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2012 |
Jan
(8) |
Feb
|
Mar
|
Apr
(3) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(10) |
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Yufei C. <cyf...@gm...> - 2010-10-17 07:17:14
|
On Sat, Oct 16, 2010 at 4:53 AM, Antti P Miettinen <an...@ik...> wrote: > From: Chen Yufei <cyf...@gm...> >> We've incorporated Antti P Miettinen's patch for ARM. The arm target can now >> use network. Thanks for Antti's effort. > > Please note that the changes are insufficient for making the > networking stable. My test guest is realview PBX with 4xCortex-A9 and > I do still get hangs when booting NFS root filesystem, maybe about 50% > success rate. I've also tried adding signal blocking here and there > but haven't been able to make the system robust. Sorry for the mistake. Actually I've struggled for the NFS boot configuration for a while, and just tested wether I can boot up the system. (Debian lenny's nfs-kernel-server package seems not playing well with our customized kernel. After using the kernel supplied by Debian, I didn't encountered NFS hang boot up hang using your patch.) > > The spinlock related changes should probably be reverted as those > should not have any effect in system mode. > > It would be good to have a nice small repeatable test case that would > stress the interrupt handling and invalidation code. > > -- > http://www.iki.fi/~ananaza/ > -- Best regards, Chen Yufei |
|
From: Antti P M. <an...@ik...> - 2010-10-15 20:53:58
|
From: Chen Yufei <cyf...@gm...> > We've incorporated Antti P Miettinen's patch for ARM. The arm target can now > use network. Thanks for Antti's effort. Please note that the changes are insufficient for making the networking stable. My test guest is realview PBX with 4xCortex-A9 and I do still get hangs when booting NFS root filesystem, maybe about 50% success rate. I've also tried adding signal blocking here and there but haven't been able to make the system robust. The spinlock related changes should probably be reverted as those should not have any effect in system mode. It would be good to have a nice small repeatable test case that would stress the interrupt handling and invalidation code. -- http://www.iki.fi/~ananaza/ |
|
From: Chen Y. <cyf...@gm...> - 2010-10-15 13:39:42
|
We've incorporated Antti P Miettinen's patch for ARM. The arm target can now use network. Thanks for Antti's effort. We plan to add x86 network support soon. -- Best regards, Chen Yufei |
|
From: Antti P M. <an...@ik...> - 2010-10-14 05:21:03
|
From: Yufei Chen <cyf...@gm...> > I choose the name to be gmane.comp.emulators.qemu.coremu, but I didn't > get a confirmation email from gmane. Maybe something went wrong somewhere then. I could try again if that is ok for you. -- http://www.iki.fi/~ananaza/ |
|
From: wang T. <tig...@gm...> - 2010-10-13 15:25:46
|
2010/10/13 Antti P Miettinen <an...@ik...> > > But the thing I'm a bit confused about is the protection of the > > TBs. > > Having read the code a bit more - if the ifdef in arm_pic_init_cpu() > is reversed and the idea is that interrupts are delivered with signals > instead of e.g. run as bh's in main thread, then the TB unchaining > cannot use a spinlock for protection. And seems that the spinlocks are > not even compiled in for system mode :-) > > Anyway - for protecting the TB structures, signals should be blocked > for sections racing with the signal handler, right? > In the function cpu_unlink_tb, TB is unchained only if env->current_tb is not NULL. This condition protects the TB unchained from races in QEMU, so spinlock is not compiled in the system mode. In COREMU, I have fixed the problem by setting the current_tb to NULL before handling the tb invalidation. We have pushed all the changes to sourceforge. We will merge your changes after testing. Thanks for your effort. :-) So only the invalidation stuff needs coordination between threads? But > is it so that cross cpu invalidation is not done if --cross-mod-code > is not given to configure? Seems that --cros-mod-code is missing some > ARM target support. I tried adding the cpuid stuff - is that enough? > > This configuration is used to support for cross-modifying code and is architecture independent. We believe cross-modifying code are rare, so this configuration is turned off by default. > -- > http://www.iki.fi/~ananaza/ > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Coremu-list-devel mailing list > Cor...@li... > https://lists.sourceforge.net/lists/listinfo/coremu-list-devel > -- Zhaoguo Wang, Parallel Processing Institute, Fudan University Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China tig...@gm... http://ppi.fudan.edu.cn/zhaoguo_wang |
|
From: wang T. <tig...@gm...> - 2010-10-13 14:32:20
|
2010/10/12 Antti P Miettinen <an...@ik...> > > We released two git repositories we used internally. > > > > One contains the coremu library source tree, the other is a clone of > > the QEMU source tree which we patched on. You can get these two > > repositories using > > > > git clone git://git.code.sf.net/p/coremu/coremu.git > > git clone git://git.code.sf.net/p/coremu/qemu.git > > > > Hope this two repositories would make it easier for people who want to > > work on COREMU. We will no longer update the original repository. > > Excellent. > > I've put my current changes to git://epm0.nrln.net/git/coremu-apm.git > repo, my branch there is coremu_apm. It seems that there are more > things to protect than just the peripheral state. The call stacks > related to interaction of lan9118 emulation and tun/tap seem to lead > to a bit surprising situations, which means that the NetQueue in > net/queue.c would need protection and maybe even the io_handlers queue > in vl.c. But I'm not at all sure of my changes related to this. > > I also added atomic implementation of the SWP instruction. > > But the thing I'm a bit confused about is the protection of the > TBs. There seem to be two locks related to those: interrupt_lock and > tb_lock. The interrupt_lock is local to cpu_interrupt() but the TB > links are manipulated e.g. in tb_link_page(). And both locks are > thread specific in COREMU meaning that now they do not protect > separate threads from each other. Why? > > Anyway - the changes to TB protection I've made are clearly not > sufficient. Also, one needs to be careful with the locks to avoid > deadlocks. > > Then I noticed the following in hw/arm_pic.c: > > qemu_irq *arm_pic_init_cpu(CPUState *env) > { > #ifdef CONFIG_COREMU > return qemu_allocate_irqs(arm_pic_cpu_handler, env, 2); > #else > return qemu_allocate_irqs(cm_arm_pic_cpu_handler, env, 2); > #endif > } > > This code seems a big mistake. The correct code should be qemu_irq *arm_pic_init_cpu(CPUState *env) { #ifdef CONFIG_COREMU return qemu_allocate_irqs(cm_arm_pic_cpu_handler, env, 2); #else return qemu_allocate_irqs(arm_pic_cpu_handler, env, 2); #endif } The definition of cm_arm_pic_cpu_handler is in the cm-target-intr.c in the target-arm directory. We emulate interrupt with real time signal and non-blocking structure. We will fix it as soon as possible and update the repository. > Is the ifdef this way on purpose? > > -- > http://www.iki.fi/~ananaza/ > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Coremu-list-devel mailing list > Cor...@li... > https://lists.sourceforge.net/lists/listinfo/coremu-list-devel > -- Zhaoguo Wang, Parallel Processing Institute, Fudan University Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China tig...@gm... http://ppi.fudan.edu.cn/zhaoguo_wang |
|
From: Antti P M. <an...@ik...> - 2010-10-13 13:55:09
|
> But the thing I'm a bit confused about is the protection of the > TBs. Having read the code a bit more - if the ifdef in arm_pic_init_cpu() is reversed and the idea is that interrupts are delivered with signals instead of e.g. run as bh's in main thread, then the TB unchaining cannot use a spinlock for protection. And seems that the spinlocks are not even compiled in for system mode :-) Anyway - for protecting the TB structures, signals should be blocked for sections racing with the signal handler, right? So only the invalidation stuff needs coordination between threads? But is it so that cross cpu invalidation is not done if --cross-mod-code is not given to configure? Seems that --cros-mod-code is missing some ARM target support. I tried adding the cpuid stuff - is that enough? -- http://www.iki.fi/~ananaza/ |
|
From: Antti P M. <an...@ik...> - 2010-10-12 04:46:19
|
> We released two git repositories we used internally. > > One contains the coremu library source tree, the other is a clone of > the QEMU source tree which we patched on. You can get these two > repositories using > > git clone git://git.code.sf.net/p/coremu/coremu.git > git clone git://git.code.sf.net/p/coremu/qemu.git > > Hope this two repositories would make it easier for people who want to > work on COREMU. We will no longer update the original repository. Excellent. I've put my current changes to git://epm0.nrln.net/git/coremu-apm.git repo, my branch there is coremu_apm. It seems that there are more things to protect than just the peripheral state. The call stacks related to interaction of lan9118 emulation and tun/tap seem to lead to a bit surprising situations, which means that the NetQueue in net/queue.c would need protection and maybe even the io_handlers queue in vl.c. But I'm not at all sure of my changes related to this. I also added atomic implementation of the SWP instruction. But the thing I'm a bit confused about is the protection of the TBs. There seem to be two locks related to those: interrupt_lock and tb_lock. The interrupt_lock is local to cpu_interrupt() but the TB links are manipulated e.g. in tb_link_page(). And both locks are thread specific in COREMU meaning that now they do not protect separate threads from each other. Why? Anyway - the changes to TB protection I've made are clearly not sufficient. Also, one needs to be careful with the locks to avoid deadlocks. Then I noticed the following in hw/arm_pic.c: qemu_irq *arm_pic_init_cpu(CPUState *env) { #ifdef CONFIG_COREMU return qemu_allocate_irqs(arm_pic_cpu_handler, env, 2); #else return qemu_allocate_irqs(cm_arm_pic_cpu_handler, env, 2); #endif } Is the ifdef this way on purpose? -- http://www.iki.fi/~ananaza/ |
|
From: Yufei C. <cyf...@gm...> - 2010-10-11 13:01:04
|
We released two git repositories we used internally. One contains the coremu library source tree, the other is a clone of the QEMU source tree which we patched on. You can get these two repositories using git clone git://git.code.sf.net/p/coremu/coremu.git git clone git://git.code.sf.net/p/coremu/qemu.git Hope this two repositories would make it easier for people who want to work on COREMU. We will no longer update the original repository. -- Best regards, Chen Yufei |
|
From: Yufei C. <cyf...@gm...> - 2010-10-10 13:43:15
|
On Sun, Oct 10, 2010 at 4:13 PM, Antti P Miettinen <an...@ik...> wrote: > From: Chen Yufei <cyf...@gm...> >>> For easier working with QEMU mainline it would very useful to have >>> your QEMU specific source tree be a clone of the mainline QEMU tree and >>> have your work in a branch. The rest of the COREMU could be a separate >>> GIT tree. >> >> Actually we have these two GIT trees. As the development history is >> a cluttered and we want to make the user easier to checkout COREMU >> code, we published the two trees in a single tree. > > It is OK to publish a tree containing a snapshot of the QEMU tree but > could you also publish the git tree that has the QEMU history? If I > want to integrate my own local changes to your work I have to manually > extract your QEMU diff from the COREMU tree every time there is a > change to COREMU. This is error prone. If your QEMU tree would be > available as a clone of the QEMU git tree I could use normal git > fetch/merge tools. > OK. We will publish the two trees we used on sourceforge soon, and we will announce it when it's ready. >>> How would you feel about mirroring your list to gmane.org? >> >> We've tried to add our list to gmane.org, maybe it takes some time >> to see the results? > > What was the news group name that you chose? I choose the name to be gmane.comp.emulators.qemu.coremu, but I didn't get a confirmation email from gmane. > >>> By the way - how are simular issues handled for x86? >> >> We use lock for ARM because we are not familiar with ARM. For x86, >> we allow concurrent access to hardware. >> >> By observing some device drivers in linux, we have a hypothethis >> that drivers in OS have already ensured correct synchronization on >> concurrent hardware accesses. >> >> For example, when emulating IDE with bus master DMA, >> 1. Two VCPUs will not send disk w/r requests at the same time. >> 2. New DMA request will not be sent until the previous one has completed. >> These two points guarantee the emulated IDE with DMA can be >> concurrently accessed by either VCPU thread or hw thread with no >> additional locks. > > This scheme may work for some peripherals. What you describe is an > implicit protocol between the CPU and the peripheral. When the CPU > triggers a DMA transfer it passes the ownership of the device to the > peripheral. When the peripheral generates an interrupt it passes the > ownership of the device to the CPU. However, this is not sufficient > for all peripherals and the FIFOs in SMSC LAN9118 are a good example > of hardware structures requiring protection. It is possible that a CPU > is popping from a FIFO at the same time that the peripheral is pushing > to the same FIFO. The integrity of the FIFO needs to be ensured for > these cases. And indeed, without the protection, the FIFO pointers in > the 9118 emulation do get out of sync and boot from NFS root hangs or > crashes QEMU. > > I guess if we want fine grained locking, each device requiring > protection should have it's own lock. Or maybe in some cases atomic > operations could be used to implement lock free updates to the data > structures. Yes, you are right. Global locking is not efficient. To achieve fine grained locking, for both options, we have to solve the problem for the devices one by one. It could be best If we can find a systematic way to solve the problem. > > -- > http://www.iki.fi/~ananaza/ > -- Best regards, Chen Yufei |
|
From: Antti P M. <an...@ik...> - 2010-10-10 08:13:40
|
From: Chen Yufei <cyf...@gm...> >> For easier working with QEMU mainline it would very useful to have >> your QEMU specific source tree be a clone of the mainline QEMU tree and >> have your work in a branch. The rest of the COREMU could be a separate >> GIT tree. > > Actually we have these two GIT trees. As the development history is > a cluttered and we want to make the user easier to checkout COREMU > code, we published the two trees in a single tree. It is OK to publish a tree containing a snapshot of the QEMU tree but could you also publish the git tree that has the QEMU history? If I want to integrate my own local changes to your work I have to manually extract your QEMU diff from the COREMU tree every time there is a change to COREMU. This is error prone. If your QEMU tree would be available as a clone of the QEMU git tree I could use normal git fetch/merge tools. >> How would you feel about mirroring your list to gmane.org? > > We've tried to add our list to gmane.org, maybe it takes some time > to see the results? What was the news group name that you chose? >> By the way - how are simular issues handled for x86? > > We use lock for ARM because we are not familiar with ARM. For x86, > we allow concurrent access to hardware. > > By observing some device drivers in linux, we have a hypothethis > that drivers in OS have already ensured correct synchronization on > concurrent hardware accesses. > > For example, when emulating IDE with bus master DMA, > 1. Two VCPUs will not send disk w/r requests at the same time. > 2. New DMA request will not be sent until the previous one has completed. > These two points guarantee the emulated IDE with DMA can be > concurrently accessed by either VCPU thread or hw thread with no > additional locks. This scheme may work for some peripherals. What you describe is an implicit protocol between the CPU and the peripheral. When the CPU triggers a DMA transfer it passes the ownership of the device to the peripheral. When the peripheral generates an interrupt it passes the ownership of the device to the CPU. However, this is not sufficient for all peripherals and the FIFOs in SMSC LAN9118 are a good example of hardware structures requiring protection. It is possible that a CPU is popping from a FIFO at the same time that the peripheral is pushing to the same FIFO. The integrity of the FIFO needs to be ensured for these cases. And indeed, without the protection, the FIFO pointers in the 9118 emulation do get out of sync and boot from NFS root hangs or crashes QEMU. I guess if we want fine grained locking, each device requiring protection should have it's own lock. Or maybe in some cases atomic operations could be used to implement lock free updates to the data structures. -- http://www.iki.fi/~ananaza/ |
|
From: Chen Y. <cyf...@gm...> - 2010-10-09 14:05:10
|
On 2010-10-9, at 下午4:40, Antti P Miettinen wrote: > Hello COREMU developers, > > I have been looking into COREMU and am very impressed by your work. I > think parallelizing QEMU is essential for future. > > For easier working with QEMU mainline it would very useful to have > your QEMU specific source tree be a clone of the mainline QEMU tree and > have your work in a branch. The rest of the COREMU could be a separate > GIT tree. Actually we have these two GIT trees. As the development history is a cluttered and we want to make the user easier to checkout COREMU code, we published the two trees in a single tree. > > How would you feel about mirroring your list to gmane.org? We've tried to add our list to gmane.org, maybe it takes some time to see the results? > > I've been using QEMU for emulating ARM based systems and usually my > setup is based on booting from NFS root. So I ran into an issue with > the SMSC LAN9118 emulation. It is missing protection between accesses > from the CPU emulation threads and the main thread (you call it HW > thread?), notably lan9118_receive(). However, adding the protection > with cm_hw_lock requires moving the lan9118 object to the ARM specific > objects in order to make the headers visible so the below patch is a > bit ugly. There are also some cosmetic changes to the 9118 emulation > that should not really have any effect on functionality but it seems > that some numbers are a bit off compared to 9118 documentation (word > vs byte counts). Thanks for your interest in COREMU. We will look at your patch and merge it into COREMU. > > I suppose similar protection would be needed for all HW emulations > that have call hooks from the main thread. So probably the protection > should be higher in the call stack. I'm not familiar enough with > COREMU to suggest a specific solution :-) > > By the way - how are simular issues handled for x86? We use lock for ARM because we are not familiar with ARM. For x86, we allow concurrent access to hardware. By observing some device drivers in linux, we have a hypothethis that drivers in OS have already ensured correct synchronization on concurrent hardware accesses. For example, when emulating IDE with bus master DMA, 1. Two VCPUs will not send disk w/r requests at the same time. 2. New DMA request will not be sent until the previous one has completed. These two points guarantee the emulated IDE with DMA can be concurrently accessed by either VCPU thread or hw thread with no additional locks. The only work we need to do is to fix some misbehaving emulated device in current QEMU. (Although these work needs much debugging time.) We have already discussed this issue in the QEMU mailing list. You can find it here http://article.gmane.org/gmane.comp.emulators.qemu/76921 -- Best regards, Chen Yufei > > -- > http://www.iki.fi/~ananaza/ > > diff --git a/qemu/Makefile.objs b/qemu/Makefile.objs > index ecdd53e..9e14543 100644 > --- a/qemu/Makefile.objs > +++ b/qemu/Makefile.objs > @@ -184,7 +184,6 @@ hw-obj-y += eepro100.o > hw-obj-y += pcnet.o > > hw-obj-$(CONFIG_SMC91C111) += smc91c111.o > -hw-obj-$(CONFIG_LAN9118) += lan9118.o > hw-obj-$(CONFIG_NE2000_ISA) += ne2000-isa.o > > # IDE > diff --git a/qemu/Makefile.target b/qemu/Makefile.target > index aec7f12..5f599af 100644 > --- a/qemu/Makefile.target > +++ b/qemu/Makefile.target > @@ -260,6 +260,7 @@ obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o > obj-arm-y += versatile_pci.o > obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o > obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o > +obj-arm-$(CONFIG_LAN9118) += lan9118.o > obj-arm-y += pl061.o > obj-arm-y += arm-semi.o > obj-arm-y += pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o > diff --git a/qemu/hw/lan9118.c b/qemu/hw/lan9118.c > index 16d3330..37e77c2 100644 > --- a/qemu/hw/lan9118.c > +++ b/qemu/hw/lan9118.c > @@ -7,6 +7,13 @@ > * This code is licenced under the GNU GPL v2 > */ > > +#include <sys/syscall.h> > +#include <pthread.h> > +#include "coremu-config.h" > +#include "coremu-spinlock.h" > +#include "cm-target-intr.h" > +#include "coremu-hw.h" > + > #include "sysbus.h" > #include "net.h" > #include "devices.h" > @@ -194,16 +201,16 @@ typedef struct { > > int tx_status_fifo_used; > int tx_status_fifo_head; > - uint32_t tx_status_fifo[512]; > + uint32_t tx_status_fifo[128]; /* fixed to 512 bytes, 128 words */ > > int rx_status_fifo_size; > int rx_status_fifo_used; > int rx_status_fifo_head; > - uint32_t rx_status_fifo[896]; > + uint32_t rx_status_fifo[224]; /* max size 896 bytes, 224 words */ > int rx_fifo_size; > int rx_fifo_used; > int rx_fifo_head; > - uint32_t rx_fifo[3360]; > + uint32_t rx_fifo[3360]; /* max size 13440 bytes, 3360 words */ > int rx_packet_size_head; > int rx_packet_size_tail; > int rx_packet_size[1024]; > @@ -217,6 +224,9 @@ static void lan9118_update(lan9118_state *s) > { > int level; > > + DPRINTF("%d: RX fifo used: %d, RX status fifo used: %d\n", > + (int)syscall(SYS_gettid), > + (int)s->rx_fifo_used, (int)s->rx_status_fifo_used); > /* TODO: Implement FIFO level IRQs. */ > level = (s->int_sts & s->int_en) != 0; > if (level) { > @@ -309,9 +319,14 @@ static void lan9118_reset(DeviceState *d) > s->txp->cmd_b = 0xffffffffu; > s->txp->len = 0; > s->txp->fifo_used = 0; > + /* TX_FIF_SZ=5 > + * tx data fifo: 4608 bytes, 1152 words > + * tx status fifo: 512 bytes, 128 words > + * rx data fifo: 10560 bytes, 2640 words > + * rx status fifo: 704 bytes, 176 words > + */ > s->tx_fifo_size = 4608; > s->tx_status_fifo_used = 0; > - s->rx_status_fifo_size = 704; > s->rx_fifo_size = 2640; > s->rx_fifo_used = 0; > s->rx_status_fifo_size = 176; > @@ -319,7 +334,7 @@ static void lan9118_reset(DeviceState *d) > s->rxp_offset = 0; > s->rxp_size = 0; > s->rxp_pad = 0; > - s->rx_packet_size_tail = s->rx_packet_size_head; > + s->rx_packet_size_tail = s->rx_packet_size_head = 0; > s->rx_packet_size[s->rx_packet_size_head] = 0; > s->mac_cmd = 0; > s->mac_data = 0; > @@ -357,6 +372,7 @@ static void rx_fifo_push(lan9118_state *s, uint32_t val) > if (fifo_pos >= s->rx_fifo_size) > fifo_pos -= s->rx_fifo_size; > s->rx_fifo[fifo_pos] = val; > + assert(s->rx_fifo_used < s->rx_fifo_size); > s->rx_fifo_used++; > } > > @@ -411,21 +427,46 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, > uint32_t crc; > uint32_t status; > > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_lock(&cm_hw_lock); > +#endif > + > + DPRINTF("%d: RX fifo used: %d, RX status fifo used: %d\n", > + (int)syscall(SYS_gettid), > + (int)s->rx_fifo_used, (int)s->rx_status_fifo_used); > + > if ((s->mac_cr & MAC_CR_RXEN) == 0) { > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_unlock(&cm_hw_lock); > +#endif > return -1; > } > > if (size >= 2048 || size < 14) { > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_unlock(&cm_hw_lock); > +#endif > return -1; > } > > /* TODO: Implement FIFO overflow notification. */ > if (s->rx_status_fifo_used == s->rx_status_fifo_size) { > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_unlock(&cm_hw_lock); > +#endif > return -1; > } > > filter = lan9118_filter(s, buf); > if (!filter && (s->mac_cr & MAC_CR_RXALL) == 0) { > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_unlock(&cm_hw_lock); > +#endif > return size; > } > > @@ -435,6 +476,12 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, > /* Add a word for the CRC. */ > fifo_len++; > if (s->rx_fifo_size - s->rx_fifo_used < fifo_len) { > + DPRINTF("RX fifo used: %d, fifo len: %d\n", > + (int)s->rx_fifo_used, (int)fifo_len); > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_unlock(&cm_hw_lock); > +#endif > return -1; > } > > @@ -466,6 +513,7 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, > } > s->rx_packet_size[s->rx_packet_size_tail] = fifo_len; > s->rx_packet_size_tail = (s->rx_packet_size_tail + 1023) & 1023; > + assert(s->rx_status_fifo_used < s->rx_status_fifo_size); > s->rx_status_fifo_used++; > > status = (size + 4) << 16; > @@ -483,6 +531,10 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, > if (s->rx_status_fifo_used > (s->fifo_int & 0xff)) { > s->int_sts |= RSFL_INT; > } > +#ifdef CONFIG_COREMU > + if(coremu_hw_thr_p()) > + coremu_spin_unlock(&cm_hw_lock); > +#endif > lan9118_update(s); > > return size; > @@ -525,6 +577,7 @@ static uint32_t rx_fifo_pop(lan9118_state *s) > if (s->rx_fifo_head >= s->rx_fifo_size) { > s->rx_fifo_head -= s->rx_fifo_size; > } > + assert(s->rx_fifo_used > 0); > s->rx_fifo_used--; > } else if (s->rxp_pad > 0) { > s->rxp_pad--; > @@ -552,17 +605,19 @@ static void do_tx_packet(lan9118_state *s) > } > s->txp->fifo_used = 0; > > - if (s->tx_status_fifo_used == 512) { > + assert(s->tx_status_fifo_used <= 128); > + if (s->tx_status_fifo_used == 128) { > /* Status FIFO full */ > return; > } > /* Add entry to status FIFO. */ > status = s->txp->cmd_b & 0xffff0000u; > DPRINTF("Sent packet tag:%04x len %d\n", status >> 16, s->txp->len); > - n = (s->tx_status_fifo_head + s->tx_status_fifo_used) & 511; > + n = (s->tx_status_fifo_head + s->tx_status_fifo_used) & 127; > s->tx_status_fifo[n] = status; > + assert(s->tx_status_fifo_used < 128); > s->tx_status_fifo_used++; > - if (s->tx_status_fifo_used == 512) { > + if (s->tx_status_fifo_used == 128) { > s->int_sts |= TSFF_INT; > /* TODO: Stop transmission. */ > } > @@ -574,6 +629,7 @@ static uint32_t rx_status_fifo_pop(lan9118_state *s) > > val = s->rx_status_fifo[s->rx_status_fifo_head]; > if (s->rx_status_fifo_used != 0) { > + assert(s->rx_status_fifo_used > 0); > s->rx_status_fifo_used--; > s->rx_status_fifo_head++; > if (s->rx_status_fifo_head >= s->rx_status_fifo_size) { > @@ -591,8 +647,9 @@ static uint32_t tx_status_fifo_pop(lan9118_state *s) > > val = s->tx_status_fifo[s->tx_status_fifo_head]; > if (s->tx_status_fifo_used != 0) { > + assert(s->tx_status_fifo_used > 0); > s->tx_status_fifo_used--; > - s->tx_status_fifo_head = (s->tx_status_fifo_head + 1) & 511; > + s->tx_status_fifo_head = (s->tx_status_fifo_head + 1) & 127; > /* ??? What value should be returned when the FIFO is empty? */ > } > return val; > @@ -602,6 +659,7 @@ static void tx_fifo_push(lan9118_state *s, uint32_t val) > { > int n; > > + assert(s->txp->fifo_used < s->tx_fifo_size); > if (s->txp->fifo_used == s->tx_fifo_size) { > s->int_sts |= TDFO_INT; > return; > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Coremu-list-devel mailing list > Cor...@li... > https://lists.sourceforge.net/lists/listinfo/coremu-list-devel |
|
From: Antti P M. <an...@ik...> - 2010-10-09 09:13:25
|
Hello COREMU developers, I have been looking into COREMU and am very impressed by your work. I think parallelizing QEMU is essential for future. For easier working with QEMU mainline it would very useful to have your QEMU specific source tree be a clone of the mainline QEMU tree and have your work in a branch. The rest of the COREMU could be a separate GIT tree. How would you feel about mirroring your list to gmane.org? I've been using QEMU for emulating ARM based systems and usually my setup is based on booting from NFS root. So I ran into an issue with the SMSC LAN9118 emulation. It is missing protection between accesses from the CPU emulation threads and the main thread (you call it HW thread?), notably lan9118_receive(). However, adding the protection with cm_hw_lock requires moving the lan9118 object to the ARM specific objects in order to make the headers visible so the below patch is a bit ugly. There are also some cosmetic changes to the 9118 emulation that should not really have any effect on functionality but it seems that some numbers are a bit off compared to 9118 documentation (word vs byte counts). I suppose similar protection would be needed for all HW emulations that have call hooks from the main thread. So probably the protection should be higher in the call stack. I'm not familiar enough with COREMU to suggest a specific solution :-) By the way - how are simular issues handled for x86? -- http://www.iki.fi/~ananaza/ diff --git a/qemu/Makefile.objs b/qemu/Makefile.objs index ecdd53e..9e14543 100644 --- a/qemu/Makefile.objs +++ b/qemu/Makefile.objs @@ -184,7 +184,6 @@ hw-obj-y += eepro100.o hw-obj-y += pcnet.o hw-obj-$(CONFIG_SMC91C111) += smc91c111.o -hw-obj-$(CONFIG_LAN9118) += lan9118.o hw-obj-$(CONFIG_NE2000_ISA) += ne2000-isa.o # IDE diff --git a/qemu/Makefile.target b/qemu/Makefile.target index aec7f12..5f599af 100644 --- a/qemu/Makefile.target +++ b/qemu/Makefile.target @@ -260,6 +260,7 @@ obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o obj-arm-y += versatile_pci.o obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o +obj-arm-$(CONFIG_LAN9118) += lan9118.o obj-arm-y += pl061.o obj-arm-y += arm-semi.o obj-arm-y += pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o diff --git a/qemu/hw/lan9118.c b/qemu/hw/lan9118.c index 16d3330..37e77c2 100644 --- a/qemu/hw/lan9118.c +++ b/qemu/hw/lan9118.c @@ -7,6 +7,13 @@ * This code is licenced under the GNU GPL v2 */ +#include <sys/syscall.h> +#include <pthread.h> +#include "coremu-config.h" +#include "coremu-spinlock.h" +#include "cm-target-intr.h" +#include "coremu-hw.h" + #include "sysbus.h" #include "net.h" #include "devices.h" @@ -194,16 +201,16 @@ typedef struct { int tx_status_fifo_used; int tx_status_fifo_head; - uint32_t tx_status_fifo[512]; + uint32_t tx_status_fifo[128]; /* fixed to 512 bytes, 128 words */ int rx_status_fifo_size; int rx_status_fifo_used; int rx_status_fifo_head; - uint32_t rx_status_fifo[896]; + uint32_t rx_status_fifo[224]; /* max size 896 bytes, 224 words */ int rx_fifo_size; int rx_fifo_used; int rx_fifo_head; - uint32_t rx_fifo[3360]; + uint32_t rx_fifo[3360]; /* max size 13440 bytes, 3360 words */ int rx_packet_size_head; int rx_packet_size_tail; int rx_packet_size[1024]; @@ -217,6 +224,9 @@ static void lan9118_update(lan9118_state *s) { int level; + DPRINTF("%d: RX fifo used: %d, RX status fifo used: %d\n", + (int)syscall(SYS_gettid), + (int)s->rx_fifo_used, (int)s->rx_status_fifo_used); /* TODO: Implement FIFO level IRQs. */ level = (s->int_sts & s->int_en) != 0; if (level) { @@ -309,9 +319,14 @@ static void lan9118_reset(DeviceState *d) s->txp->cmd_b = 0xffffffffu; s->txp->len = 0; s->txp->fifo_used = 0; + /* TX_FIF_SZ=5 + * tx data fifo: 4608 bytes, 1152 words + * tx status fifo: 512 bytes, 128 words + * rx data fifo: 10560 bytes, 2640 words + * rx status fifo: 704 bytes, 176 words + */ s->tx_fifo_size = 4608; s->tx_status_fifo_used = 0; - s->rx_status_fifo_size = 704; s->rx_fifo_size = 2640; s->rx_fifo_used = 0; s->rx_status_fifo_size = 176; @@ -319,7 +334,7 @@ static void lan9118_reset(DeviceState *d) s->rxp_offset = 0; s->rxp_size = 0; s->rxp_pad = 0; - s->rx_packet_size_tail = s->rx_packet_size_head; + s->rx_packet_size_tail = s->rx_packet_size_head = 0; s->rx_packet_size[s->rx_packet_size_head] = 0; s->mac_cmd = 0; s->mac_data = 0; @@ -357,6 +372,7 @@ static void rx_fifo_push(lan9118_state *s, uint32_t val) if (fifo_pos >= s->rx_fifo_size) fifo_pos -= s->rx_fifo_size; s->rx_fifo[fifo_pos] = val; + assert(s->rx_fifo_used < s->rx_fifo_size); s->rx_fifo_used++; } @@ -411,21 +427,46 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, uint32_t crc; uint32_t status; +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_lock(&cm_hw_lock); +#endif + + DPRINTF("%d: RX fifo used: %d, RX status fifo used: %d\n", + (int)syscall(SYS_gettid), + (int)s->rx_fifo_used, (int)s->rx_status_fifo_used); + if ((s->mac_cr & MAC_CR_RXEN) == 0) { +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_unlock(&cm_hw_lock); +#endif return -1; } if (size >= 2048 || size < 14) { +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_unlock(&cm_hw_lock); +#endif return -1; } /* TODO: Implement FIFO overflow notification. */ if (s->rx_status_fifo_used == s->rx_status_fifo_size) { +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_unlock(&cm_hw_lock); +#endif return -1; } filter = lan9118_filter(s, buf); if (!filter && (s->mac_cr & MAC_CR_RXALL) == 0) { +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_unlock(&cm_hw_lock); +#endif return size; } @@ -435,6 +476,12 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, /* Add a word for the CRC. */ fifo_len++; if (s->rx_fifo_size - s->rx_fifo_used < fifo_len) { + DPRINTF("RX fifo used: %d, fifo len: %d\n", + (int)s->rx_fifo_used, (int)fifo_len); +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_unlock(&cm_hw_lock); +#endif return -1; } @@ -466,6 +513,7 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, } s->rx_packet_size[s->rx_packet_size_tail] = fifo_len; s->rx_packet_size_tail = (s->rx_packet_size_tail + 1023) & 1023; + assert(s->rx_status_fifo_used < s->rx_status_fifo_size); s->rx_status_fifo_used++; status = (size + 4) << 16; @@ -483,6 +531,10 @@ static ssize_t lan9118_receive(VLANClientState *nc, const uint8_t *buf, if (s->rx_status_fifo_used > (s->fifo_int & 0xff)) { s->int_sts |= RSFL_INT; } +#ifdef CONFIG_COREMU + if(coremu_hw_thr_p()) + coremu_spin_unlock(&cm_hw_lock); +#endif lan9118_update(s); return size; @@ -525,6 +577,7 @@ static uint32_t rx_fifo_pop(lan9118_state *s) if (s->rx_fifo_head >= s->rx_fifo_size) { s->rx_fifo_head -= s->rx_fifo_size; } + assert(s->rx_fifo_used > 0); s->rx_fifo_used--; } else if (s->rxp_pad > 0) { s->rxp_pad--; @@ -552,17 +605,19 @@ static void do_tx_packet(lan9118_state *s) } s->txp->fifo_used = 0; - if (s->tx_status_fifo_used == 512) { + assert(s->tx_status_fifo_used <= 128); + if (s->tx_status_fifo_used == 128) { /* Status FIFO full */ return; } /* Add entry to status FIFO. */ status = s->txp->cmd_b & 0xffff0000u; DPRINTF("Sent packet tag:%04x len %d\n", status >> 16, s->txp->len); - n = (s->tx_status_fifo_head + s->tx_status_fifo_used) & 511; + n = (s->tx_status_fifo_head + s->tx_status_fifo_used) & 127; s->tx_status_fifo[n] = status; + assert(s->tx_status_fifo_used < 128); s->tx_status_fifo_used++; - if (s->tx_status_fifo_used == 512) { + if (s->tx_status_fifo_used == 128) { s->int_sts |= TSFF_INT; /* TODO: Stop transmission. */ } @@ -574,6 +629,7 @@ static uint32_t rx_status_fifo_pop(lan9118_state *s) val = s->rx_status_fifo[s->rx_status_fifo_head]; if (s->rx_status_fifo_used != 0) { + assert(s->rx_status_fifo_used > 0); s->rx_status_fifo_used--; s->rx_status_fifo_head++; if (s->rx_status_fifo_head >= s->rx_status_fifo_size) { @@ -591,8 +647,9 @@ static uint32_t tx_status_fifo_pop(lan9118_state *s) val = s->tx_status_fifo[s->tx_status_fifo_head]; if (s->tx_status_fifo_used != 0) { + assert(s->tx_status_fifo_used > 0); s->tx_status_fifo_used--; - s->tx_status_fifo_head = (s->tx_status_fifo_head + 1) & 511; + s->tx_status_fifo_head = (s->tx_status_fifo_head + 1) & 127; /* ??? What value should be returned when the FIFO is empty? */ } return val; @@ -602,6 +659,7 @@ static void tx_fifo_push(lan9118_state *s, uint32_t val) { int n; + assert(s->txp->fifo_used < s->tx_fifo_size); if (s->txp->fifo_used == s->tx_fifo_size) { s->int_sts |= TDFO_INT; return; |
|
From: wang T. <tig...@gm...> - 2010-09-07 13:20:07
|
In this version, we add the smart watch point and memory trace collection mechanisms in COREMU.The code also has been pushed to the git repository with a new branch "extra-features". Documents and examples are provided. -- Zhaoguo Wang, Parallel Processing Institute, Fudan University Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China tig...@gm... http://ppi.fudan.edu.cn/zhaoguo_wang |
|
From: wang T. <tig...@gm...> - 2010-08-23 12:31:13
|
yeah~~~ it works well~ 2010/8/23 Yufei Chen <cyf...@gm...>: > is this working > > -- > Best regards, > Chen Yufei > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Coremu-list-devel mailing list > Cor...@li... > https://lists.sourceforge.net/lists/listinfo/coremu-list-devel > -- Zhaoguo Wang, Parallel Processing Institute, Fudan University Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China tig...@gm... http://ppi.fudan.edu.cn/zhaoguo_wang |
|
From: Yufei C. <cyf...@gm...> - 2010-08-23 12:30:28
|
is this working -- Best regards, Chen Yufei |
|
From: wang T. <tig...@gm...> - 2010-08-03 06:32:09
|
hi guys hello word~ -- Zhaoguo Wang, Parallel Processing Institute, Fudan University Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China tig...@gm... http://ppi.fudan.edu.cn/zhaoguo_wang |
|
From: Yufei C. <cyf...@gm...> - 2010-08-03 06:21:05
|
This is just a test for the mailing list. -- Best regards, Chen Yufei |
1 message has been excluded from this view by a project administrator.
