On 05/17/2013 12:23:51 PM, KONRAD Frédéric wrote:
On 09/05/2013 19:54, Blue Swirl wrote:
On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
wrote:
Hi,
We are trying to find a way to do reverse execution happen with
QEMU.
...
For now we tried some other things which are not working very well,
Hello All,
On Saturday 18 May 2013 23:23:28 Rempel, Cynthia wrote:
> >> Would following the guidance in:
> >> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
> >> increase the probability the [CAN] device simulation would be committed
> >> to qemu?
> >
> >Yes, I think so.
> >
>
I am trying to enable MSI interrupts in em driver on freebsd guest OS, using
Qemu e1000 emulation in 0.13.0, but it does not seem to work. After adding MSI
support in driver,
pci_msi_count() returns 0, which means probably e1000 does not support it
in 0.13.0?
How can I make e1000 device (or which
>> Would following the guidance in:
>> http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00842.html
>> increase the probability the [CAN] device simulation would be committed to
>> qemu?
>Yes, I think so.
>
>Here is also some help which shows the fundamental
>requirements for new contributio
Am 18.05.2013 20:24, schrieb Rempel, Cynthia:
>>> The RTEMS development community is considering having a Google Summer
>>> of Code student test LinCAN on a simulated RTEMS target board using
>>> QEMU, and have some questions:
>>>
>>> 1. What guidelines should the student follow when writing the de
On Fri, May 17, 2013 at 5:23 PM, KONRAD Frédéric
wrote:
> On 09/05/2013 19:54, Blue Swirl wrote:
>>
>> On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
>> wrote:
>>>
>>> Hi,
>>>
>>> We are trying to find a way to do reverse execution happen with QEMU.
>>>
>>> Actually, it is possible to debug the
>> The RTEMS development community is considering having a Google Summer
>> of Code student test LinCAN on a simulated RTEMS target board using
>> QEMU, and have some questions:
>>
>> 1. What guidelines should the student follow when writing the device >
>> simulation, so the device simulation wil
18.05.2013 19:53, Paolo Bonzini wrote:
> Il 18/05/2013 16:39, Michael Tokarev ha scritto:
>> And I don't really know how to add scsi device to qemu ppc.
>>
>> qemu-system-ppc -drive file=foo,if=scsi
> For example:
>
> qemu-system-ppc -drive file=foo,if=none,id=hd -device \
> megasas -device s
Il 18/05/2013 16:39, Michael Tokarev ha scritto:
> 18.05.2013 17:48, Michael Tokarev wrote:
>> 18.05.2013 17:39, Paolo Bonzini wrote:
>>> [] Did you test SCSI as well?
>>
>> Trying that now.
>
> And I don't really know how to add scsi device to qemu ppc.
>
> qemu-system-ppc -drive file=foo,if=sc
18.05.2013 17:48, Michael Tokarev wrote:
> 18.05.2013 17:39, Paolo Bonzini wrote:
>> [] Did you test SCSI as well?
>
> Trying that now.
And I don't really know how to add scsi device to qemu ppc.
qemu-system-ppc -drive file=foo,if=scsi
creates no scsi device in the guest, at least not one visi
Il 17/05/2013 22:29, Rempel, Cynthia ha scritto:> Hi Qemu-Devel,
> I am part of the RTEMS development community.
>
> The RTEMS development community is considering having a Google Summer
> of Code student test LinCAN on a simulated RTEMS target board using
> QEMU, and have some questions:
>
> 1.
18.05.2013 17:39, Paolo Bonzini wrote:
> Il 18/05/2013 15:30, Michael Tokarev ha scritto:
>> As mentioned in LP:1179104 ( https://bugs.launchpad.net/qemu/+bug/1179104 ),
[]
>> That's more or less a JFYI for now, but I don't really know what other info
>> is needed, -- I already provided some struct
Il 18/05/2013 15:30, Michael Tokarev ha scritto:
> As mentioned in LP:1179104 ( https://bugs.launchpad.net/qemu/+bug/1179104 ),
> there's a segfault bug in qemu process once guest tries to use some TRIM
> command against an IDE device on PPC. This makes qemu-system-ppc basically
> unusable with an
As mentioned in LP:1179104 ( https://bugs.launchpad.net/qemu/+bug/1179104 ),
there's a segfault bug in qemu process once guest tries to use some TRIM
command against an IDE device on PPC. This makes qemu-system-ppc basically
unusable with any modern distribution, since mke2fs now issues TRIM comma
Hello. We accumulated several more patches in the trivial patch
queue, all of which are simple, easy to verify and safe. One
of the patches are authored by me, -- this one removes a few more
double-includes in sources, because we were getting separate
patches removing double includes in single pl
Looks like the lack of initial bug submissions only affects the thread
indices of the archives on lists.gnu.org - the date indices are OK.
Does anyone know what might cause this and/or how to get it fixed?
--
Andreas Gustafsson, g...@gson.org
Macro MOD_SHIFT is also defined in imm.h:
/qemu/hw/arm/spitz.c:280:1: warning: "MOD_SHIFT" redefined
/usr/lib/gcc/amd64-mingw32msvc/4.4.4/../../../../amd64-mingw32msvc/include/imm.h:309:1:
warning: this is the location of the previous definition
Signed-off-by: Stefan Weil
---
hw/arm/spitz.c |
Peter Maydell wrote:
> I see initial bug reports on the mailing list. Here's one, for
> example:
> http://permalink.gmane.org/gmane.comp.emulators.qemu/211758
OTOH, I don't see any reference to bug 1180970 in the May index on
lists.gnu.org:
https://lists.gnu.org/archive/html/qemu-devel/2013-05/
Am 15.05.2013 16:44, schrieb Paolo Bonzini:
> Il 15/05/2013 16:36, Markus Armbruster ha scritto:
>> This patch would break the build for me, if I didn't configure
>> --disable-werror. Using --enable-trace-backend=stderr in case it makes
>> a difference. Troublemaker flagged inline.
> Yes, it does
On 18 May 2013 12:40, Andreas Gustafsson wrote:
> It looks to me like at least some updates to existing qemu bug reports
> on launchpad are gatewayed to the qemu-devel list, but the initial bug
> reports are not. This makes no sense to me - is it intentional?
I see initial bug reports on the mai
Builds with an enabled trace backend and -Werror fail.
Reported-by: Markus Armbruster
Cc: Paolo Bonzini
Signed-off-by: Stefan Weil
---
trace-events |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace-events b/trace-events
index c03b9cb..9c73931 100644
--- a/trace-event
Hi all,
It looks to me like at least some updates to existing qemu bug reports
on launchpad are gatewayed to the qemu-devel list, but the initial bug
reports are not. This makes no sense to me - is it intentional?
--
Andreas Gustafsson, g...@gson.org
15.05.2013 10:04, Hu Tao wrote:
> target_phys_addr_t has been already replaced by hwaddr, but this
> one is introduced after.
>
> Signed-off-by: Hu Tao
Thanks, added to the trivial patches queue.
/mjt
30.04.2013 06:59, liguang wrote:
> Signed-off-by: liguang
Thanks, applied to the trivial patches queue.
/mjt
On Sat, May 18, 2013 at 4:52 AM, Anthony Liguori wrote:
>
> Hi,
>
> On behalf of the QEMU Team, I'd like to announce the availability of the
> fourth release candidate for the QEMU 1.5 release. This release is meant
> for testing purposes and should not be used in a production environment.
>
> ht
25 matches
Mail list logo
