Re: [v2] hw: misc: edu: fix 2 off-by-one errors

[Christopher Friedt]

Hi Jiri, Peter,

Are you able to review the more recent version of this change?

Look for the subject "[PATCH v4 x/3] hw: misc: edu: ..."

I believe I addressed all concerns.

Cheers,

C


On Mon, Oct 17, 2022 at 12:36 PM Christopher Friedt
 wrote:
>
> On Mon, Oct 17, 2022 at 2:23 AM Jiri Slaby  wrote:
> > On 15. 10. 22, 23:10, Chris Friedt wrote:
> > > From: Christopher Friedt 
> > This should be split into two patches. This way, it's hard to review.
>
> I can do that :-)
>
> Thanks for the review

Re: [v2] hw: misc: edu: fix 2 off-by-one errors

[Christopher Friedt]

On Mon, Oct 17, 2022 at 2:23 AM Jiri Slaby  wrote:
> On 15. 10. 22, 23:10, Chris Friedt wrote:
> > From: Christopher Friedt 
> This should be split into two patches. This way, it's hard to review.

I can do that :-)

Thanks for the review

[PATCH v2] hw: misc: edu: fix 2 off-by-one errors

[Christopher Friedt]

In the case that size1 was zero, because of the explicit
'end1 > addr' check, the range check would fail and the error
message would read as shown below. The correct comparison
is 'end1 >= addr' (or 'addr <= end1').

EDU: DMA range 0x4-0x3 out of bounds (0x4-0x3)!

At the opposite end, in the case that size1 was 4096, within()
would fail because of the non-inclusive check 'end1 < end2',
which should have been 'end1 <= end2'. The error message would
previously say

EDU: DMA range 0x4-0x40fff out of bounds (0x4-0x40fff)!

The solution is to use non-inclusive ranges e.g. [begin,end).

Signed-off-by: Christopher Friedt 
---
 hw/misc/edu.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index e935c418d4..73e97a54e7 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -103,25 +103,21 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
 }
 }
 
-static bool within(uint64_t addr, uint64_t start, uint64_t end)
-{
-return start <= addr && addr < end;
-}
-
 static void edu_check_range(uint64_t addr, uint64_t size1, uint64_t start,
 uint64_t size2)
 {
 uint64_t end1 = addr + size1;
 uint64_t end2 = start + size2;
 
-if (within(addr, start, end2) &&
-end1 > addr && within(end1, start, end2)) {
+if (start <= addr && addr < end2 &&
+addr <= end1 &&
+start <= end1 && end1 <= end2) {
 return;
 }
 
-hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
- " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
-addr, end1 - 1, start, end2 - 1);
+hw_error("EDU: DMA range [0x%016"PRIx64", 0x%016"PRIx64")"
+ " out of bounds [0x%016"PRIx64", 0x%016"PRIx64")!",
+addr, end1, start, end2);
 }
 
 static dma_addr_t edu_clamp_addr(const EduState *edu, dma_addr_t addr)
-- 
2.30.1 (Apple Git-130)

[PATCH] hw: misc: edu: fix 2 off-by-one errors

[Christopher Friedt]

In the case that size1 was zero, because of the explicit
'end1 > addr' check, the range check would fail and the error
message would read as shown below. The correct comparison
is 'end1 >= addr' (or 'addr <= end1').

EDU: DMA range 0x4-0x3 out of bounds (0x4-0x3)!

At the opposite end, in the case that size1 was 4096, within()
would fail because of the non-inclusive check 'end1 < end2',
which should have been 'end1 <= end2'. The error message would
previously say

EDU: DMA range 0x4-0x40fff out of bounds (0x4-0x40fff)!

The solution is to use non-inclusive ranges e.g. [begin,end).

Signed-off-by: Christopher Friedt 
---
 hw/misc/edu.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index e935c418d4..73e97a54e7 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -103,25 +103,21 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
 }
 }
 
-static bool within(uint64_t addr, uint64_t start, uint64_t end)
-{
-return start <= addr && addr < end;
-}
-
 static void edu_check_range(uint64_t addr, uint64_t size1, uint64_t start,
 uint64_t size2)
 {
 uint64_t end1 = addr + size1;
 uint64_t end2 = start + size2;
 
-if (within(addr, start, end2) &&
-end1 > addr && within(end1, start, end2)) {
+if (start <= addr && addr < end2 &&
+addr <= end1 &&
+start <= end1 && end1 <= end2) {
 return;
 }
 
-hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
- " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
-addr, end1 - 1, start, end2 - 1);
+hw_error("EDU: DMA range [0x%016"PRIx64", 0x%016"PRIx64")"
+ " out of bounds [0x%016"PRIx64", 0x%016"PRIx64")!",
+addr, end1, start, end2);
 }
 
 static dma_addr_t edu_clamp_addr(const EduState *edu, dma_addr_t addr)
-- 
2.30.2

Re: [Qemu-devel] [PATCH] Fix ARM v7m gen_intermediate_code()

[Christopher Friedt]

In the end it was just incorrect alignment for my vector table

Re: [Qemu-devel] [PATCH] Fix ARM v7m gen_intermediate_code()

[Christopher Friedt]

On Thu, Aug 23, 2018 at 4:01 PM Christopher Friedt
 wrote:
> On Thu., Aug. 23, 2018, 3:50 p.m. Christopher Friedt,  
> wrote:
>> On Thu., Aug. 23, 2018, 2:20 p.m. Peter Maydell,  
>> wrote:
>>> On 23 August 2018 at 17:36, Christopher Friedt  
>>> wrote:
>>>
>>> happen to have a copy on your lake, but the short answer
>>> is that bit 1 must be set, exactly because this is what
>>> defines whether EPSR.T is set on exception entry.
>>
>> Doh! You're right, although I checked for that in my rom vector table. As it 
>> turns out, I relocated my vtable to ram and *then* zeroed bss, which would 
>> obviously clear the T bit.
>
> Ok, not right. The vtable entries all do have the T bit set and I was zeroing 
> the bss first after all. All isr entries are either 0x2e9 (no-op isr), 0x2ff 
> (no-op fault handler), or 0 (for reserved), so the T bit is set everywhere it 
> needs to be.
>
> It would seem there is an underlying issue with the T bit not getting set 
> upon exception invocation, and my previous patch was more of a bandaid 
> solution. It would be fairly straightforward to come up with a short assembly 
> fragment that verifiably demonstrates the problem in this case.

OK - assembly fragment worked fine. So yeah, it has to be something
wrong with the way that the C library I'm linking to (musl) is doing
syscalls.


foo.S
Description: Binary data

Re: [Qemu-devel] [PATCH] Fix ARM v7m gen_intermediate_code()

[Christopher Friedt]

On Thu., Aug. 23, 2018, 3:50 p.m. Christopher Friedt, 
wrote:

>
>
> On Thu., Aug. 23, 2018, 2:20 p.m. Peter Maydell, 
> wrote:
>
>> On 23 August 2018 at 17:36, Christopher Friedt 
>> wrote:
>>
>> happen to have a copy on your lake, but the short answer
>> is that bit 1 must be set, exactly because this is what
>> defines whether EPSR.T is set on exception entry.
>>
>
> Doh! You're right, although I checked for that in my rom vector table. As
> it turns out, I relocated my vtable to ram and *then* zeroed bss, which
> would obviously clear the T bit.
>

Ok, not right. The vtable entries all do have the T bit set and I was
zeroing the bss first after all. All isr entries are either 0x2e9 (no-op
isr), 0x2ff (no-op fault handler), or 0 (for reserved), so the T bit is set
everywhere it needs to be.

It would seem there is an underlying issue with the T bit not getting set
upon exception invocation, and my previous patch was more of a bandaid
solution. It would be fairly straightforward to come up with a short
assembly fragment that verifiably demonstrates the problem in this case.

Let me see what I can do.

C

>

Re: [Qemu-devel] [PATCH] Fix ARM v7m gen_intermediate_code()

[Christopher Friedt]

On Thu., Aug. 23, 2018, 2:20 p.m. Peter Maydell, 
wrote:

> On 23 August 2018 at 17:36, Christopher Friedt 
> wrote:
>
> Hi; thanks for your patch, but I don't think it is correct.
> What it does is to make QEMU ignore the T bit in the xPSR.
> The architecture says that what should happen is that attempts
> to execute with the T bit clear should cause an INVSTATE
> UsageFault, which is exactly what we do. The reason we end up
> aborting is because the CPU should really be going into
> Lockup mode (where it basically hangs indefinitely),
> and QEMU doesn't implement that.
>
> Your guest code almost certainly has a bug where it is
> not setting the low bit in the words in its exception
> vector table. See the v7M ARM ARM section B1.5.3 if you
> happen to have a copy on your lake, but the short answer
> is that bit 1 must be set, exactly because this is what
> defines whether EPSR.T is set on exception entry. If
> you tried this on real hardware it would fail in the
> same way (except that the hardware would lock up and sit
> there like a lemon rather than calling abort()).
>

Doh! You're right, although I checked for that in my rom vector table. As
it turns out, I relocated my vtable to ram and *then* zeroed bss, which
would obviously clear the T bit.

Cheers ;-)

>

[Qemu-devel] [PATCH] Fix ARM v7m gen_intermediate_code()

[Christopher Friedt]

Hi list,

I hope this message finds you well, as I'm currently on a lake in the
middle of nowhere relying on my flaky cellular connection. Roaming
sucks. In any case, I found a bug while trying to execute the "svc 0"
instruction for cortex-m3.

A UsageFault (EXCP_INVSTATE) is injected at
target/arm/translate.c:disas_arm_insn() without the patch. I noticed
because I added a log statement to the effect, so my pre-patch output
was:

$ qemu-system-arm -d int  -M netduino2 -cpu cortex-m3  -S -s
-semihosting -nographic -kernel hello.bin
Taking exception 2 [SVC]
... as 11
M variants do not implement ARM mode.
Taking exception 18 [v7M INVSTATE UsageFault]
... as 3
M variants do not implement ARM mode.
Taking exception 18 [v7M INVSTATE UsageFault]
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

R00=279c R01=008c R02= R03=000f0005
R04=271c R05=2808 R06= R07=000f0005
R08= R09= R10= R11=
R12= R13=200018e0 R14=fff1 R15=
XPSR=0003  A handler
FPSCR: 
Abort trap: 6

My post-patch output is:

$ qemu-system-arm -d int  -M netduino2 -cpu cortex-m3  -S -s
-semihosting -nographic -kernel hello.bin
Taking exception 2 [SVC]
... as 11
Taking exception 8 [QEMU v7M exception exit]
Exception return: magic PC fffd previous exception 11
...successful exception return
Taking exception 2 [SVC]
... as 11
Taking exception 8 [QEMU v7M exception exit]
Exception return: magic PC fffd previous exception 11
...successful exception return
qemu-system-arm: QEMU: Terminated via GDBstub

The patch is attached. Should be ok to go against master - i synced
before I went on vacation. Otherwise, I'd be happy to make any fixups
when I get back ;-)

Cheers,

C


qemu-system-arm-do-not-die-on-v7m-exception.patch
Description: Binary data

Re: [Qemu-devel] [PATCH 1/2v2] [RESENT-INLINE] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

On May 3, 2016 9:50 AM, "Christopher Friedt" <chrisfri...@gmail.com> wrote:
>
> On Tue, May 3, 2016 at 3:06 AM, Richard Henderson <r...@twiddle.net> wrote:
> > On 05/02/2016 03:10 PM, Christopher Friedt wrote:
> >>
> >>  %.a:
> >> +ifdef CONFIG_DARWIN
> >> +   $(call quiet-command,rm -f $@ && libtool -static -o $@ $^,"
> >> libtool$(TARGET_DIR)$@")
> >> +else
> >> $(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"  AR
> >> $(TARGET_DIR)$@")
> >> +endif
> >>
> >
> > Does it work to use libtool -static everywhere?

One possibility for future-proofing the link stage that applies to most
(all?) platforms that Qemu runs on would be to switch to libtool for all
arch's and just adjust the "libtool flags" as necessary.

Would require checking for libtool.

Fallback to ar?

©

Sent from my Android

Re: [Qemu-devel] [PATCH 1/2v2] [RESENT-INLINE] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

On Tue, May 3, 2016 at 3:06 AM, Richard Henderson <r...@twiddle.net> wrote:
> On 05/02/2016 03:10 PM, Christopher Friedt wrote:
>>
>>  %.a:
>> +ifdef CONFIG_DARWIN
>> +   $(call quiet-command,rm -f $@ && libtool -static -o $@ $^,"
>> libtool$(TARGET_DIR)$@")
>> +else
>> $(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"  AR
>> $(TARGET_DIR)$@")
>> +endif
>>
>
> Does it work to use libtool -static everywhere?

That *would* be nice... yeah, it would be nice if Apple's tools could
work the same as *all* of the other unices out there. Unfortunately,
that's not the case, since at least GNU libtool does *not* accept the
"-static" argument.

To be honest, if it weren't for the man page for libtool on Mac OS X
[1] dating all the way back to Snow Leopard saying that libtool is the
preferred tool on Mac for creating static archives, I'm left wondering
if this is just a massive oversight / bug in Apple's ld64.

[1] http://www.unix.com/man-page/osx/1/libtool/

[Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

[Christopher Friedt]

The file ivshmem.c unconditionally references event_notifier_init_fd() in 
util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined. On 
platforms where CONFIG_POSIX is defined, but CONFIG_EVENTFD is not defined, 
that results in an undefined symbol referenced from ivshmem.c and the link 
fails. That applies to Mac OS X, but possibly other BSD-based distros.

Note: there is nothing specific to eventfd inside and event_notifier_init() 
also fails unconditionally if CONFIG_EVENTFD is not defined.
Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
---
 util/event_notifier-posix.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/util/event_notifier-posix.c b/util/event_notifier-posix.c
index c1f0d79..c9bb34d 100644
--- a/util/event_notifier-posix.c
+++ b/util/event_notifier-posix.c
@@ -21,7 +21,6 @@
 #include 
 #endif
 
-#ifdef CONFIG_EVENTFD
 /*
  * Initialize @e with existing file descriptor @fd.
  * @fd must be a genuine eventfd object, emulation with pipe won't do.
@@ -31,7 +30,6 @@ void event_notifier_init_fd(EventNotifier *e, int fd)
 e->rfd = fd;
 e->wfd = fd;
 }
-#endif
 
 int event_notifier_init(EventNotifier *e, int active)
 {

[Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for a 
few reasons.

One of those reasons is that Apple's ld (at least ld64) does not properly 
process archive files created with ar (even Apple's ar).

After some RTFM'ing, I came upon this tidbit, which is unfortunate. Luckily, 
autotools packages are not broken.

"Libtool with -static is intended to replace ar(5) and ranlib."
http://www.manpages.info/macosx/libtool.1.html

In any case, this change takes Apple's recommendations into account and allows 
Qemu to build on Mac OS X El Capitan.

Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
---
 rules.mak | 4 
 1 file changed, 4 insertions(+)

diff --git a/rules.mak b/rules.mak
index d1ff311..44421af 100644
--- a/rules.mak
+++ b/rules.mak
@@ -105,7 +105,11 @@ modules:
 	$(call LINK,$(filter %.o %.a %.mo, $^))
 
 %.a:
+ifeq ($(shell uname),Darwin)
+	$(call quiet-command,rm -f $@ && libtool -static -o $@ $^,"  libtool$(TARGET_DIR)$@")
+else
 	$(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"  AR$(TARGET_DIR)$@")
+endif
 
 quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1))
 

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

[Christopher Friedt]

On Mon, May 2, 2016 at 9:18 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 3 May 2016 at 02:14, Christopher Friedt <chrisfri...@gmail.com> wrote:
>> On Mon, May 2, 2016 at 9:01 PM, Peter Maydell <peter.mayd...@linaro.org> 
>> wrote:
>>> [ccing somebody else who ran into this, since I've figured out why.]
>>>
>>> On 3 May 2016 at 01:47, Christopher Friedt <chrisfri...@gmail.com> wrote:
>>>> The file ivshmem.c unconditionally references event_notifier_init_fd()
>>>> in util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined.
>>>
>>> Yes, but ivshmem.c is only built if CONFIG_IVSHMEM, and
>>> CONFIG_IVSHMEM is set (in default-configs/pci.mak) to CONFIG_EVENTFD.
>>> So if CONFIG_EVENTFD is not defined then we should never build ivshmem.o.
>>>
>>> The problem here is that you've run into a bug in QEMU's makefiles,
>>
>> That would explain things.



> Hmm. (Is it set the same for every config-devices.mak for
> every target you're trying to build?)

Ack - too late! I manually removed all of the *-softmmu/ directories
after doing a make clean, because they were still hanging around.
Rebuilding worked fine without PATCH 2/2.

Thanks!

[Qemu-devel] [PATCH 0/2] Resolve link errors on Mac OS X

[Christopher Friedt]

Hi list,

I recently tried to build Qemu on Mac and ran into a couple of trivial issues
that I've provided patches for. I suppose that normally people just use
'brew install qemu', but there is really no reason that it can't be built from
source, particularly for those modifying Qemu regularly.

In any case, the first change moves to using 'libtool -static' to create
libraries on Mac OS X. If one attempts to use ar and ranlib, then the final
link will fail with error messages resembling the following:

  ld: warning: ignoring file libqemuutil.a, file was built for archive which
  is not the architecture being linked (x86_64): libqemuutil.a
  Undefined symbols for architecture x86_64:
  ...

Notice ld (Apple's ld64) presumes the static library is a relocatable with
architecture 'archive' rather than x86_64, in this case.

A similar fix is required for dtc - again quite trivial, but I can provide that 
if necessary.

The second patch removes the preprocessor conditional around the function
event_notifier_init_fd() in util/event_notifier-posix.c so that the link does
not fail on systems where CONFIG_POSIX is defined but CONFIG_EVENTFD is not
(such as under Mac OS X).

There is more information in each of the commits that follows.

Please feel free to comment.

Cheers,

C

Christopher Friedt (2):
  Use libtool instead of ar to create static libraries on Darwin.
  Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy
link

 rules.mak   | 4 
 util/event_notifier-posix.c | 2 --
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.6.4 (Apple Git-63)

Re: [Qemu-devel] [PATCH 2/2] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

[Christopher Friedt]

On Mon, May 2, 2016 at 9:01 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> [ccing somebody else who ran into this, since I've figured out why.]
>
> On 3 May 2016 at 01:47, Christopher Friedt <chrisfri...@gmail.com> wrote:
>> The file ivshmem.c unconditionally references event_notifier_init_fd()
>> in util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined.
>
> Yes, but ivshmem.c is only built if CONFIG_IVSHMEM, and
> CONFIG_IVSHMEM is set (in default-configs/pci.mak) to CONFIG_EVENTFD.
> So if CONFIG_EVENTFD is not defined then we should never build ivshmem.o.
>
> The problem here is that you've run into a bug in QEMU's makefiles,

That would explain things.

> where a change in an included .mak file in default-configs fails
> to cause the config-devices.mak file to be rebuilt. In commit
> 330b583 we changed pci.mak so that CONFIG_IVSHMEM is set to
> CONFIG_EVENTFD rather than CONFIG_POSIX, so if your config-devices.mak
> predates that commit then it will have incorrectly not been recreated
> and so your build will still try to build ivshmem.c.
>
> You can check whether this is true by looking at
> (for instance) x86_64-softmmu/config-devices.mak in your build
> tree: if it has a line "CONFIG_IVSHMEM=$(CONFIG_POSIX)" in it
> then it's the out of date version.

$ grep "CONFIG_IVSHMEM" x86_64-softmmu/config-devices.mak
CONFIG_IVSHMEM=$(CONFIG_EVENTFD)

I have been re-configuring on every build, just to eliminate that
potential error source.

> You should be able to fix this by deleting */config-devices.mak
> from your build tree (or by blowing away the build tree entirely
> and recreating it.) Then try rebuilding -- ivshmem.c should not
> be compiled.

I'll give that a go anyway.

[Qemu-devel] [PATCH 1/2v2] [RESENT-INLINE] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for a 
few reasons.

One of those reasons is that Apple's ld (at least ld64) does not properly 
process archive files created with ar (even Apple's ar).

After some RTFM'ing, I came upon this tidbit, which is unfortunate. Luckily, 
autotools packages are not broken.

"Libtool with -static is intended to replace ar(5) and ranlib."
http://www.manpages.info/macosx/libtool.1.html

In any case, this change takes Apple's recommendations into account and allows 
Qemu to build on Mac OS X El Capitan.

Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
---
 rules.mak | 4 
 1 file changed, 4 insertions(+)

diff --git a/rules.mak b/rules.mak
index d1ff311..44421af 100644
--- a/rules.mak
+++ b/rules.mak
@@ -105,7 +105,11 @@ modules:
$(call LINK,$(filter %.o %.a %.mo, $^))
 
 %.a:
+ifdef CONFIG_DARWIN
+   $(call quiet-command,rm -f $@ && libtool -static -o $@ $^,"  libtool
$(TARGET_DIR)$@")
+else
$(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"  AR
$(TARGET_DIR)$@")
+endif
 
 quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1))
 
-- 
2.6.4 (Apple Git-63)

Re: [Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

On Mon, May 2, 2016 at 9:04 PM, Fam Zheng <f...@redhat.com> wrote:
> Cc'ing Peter Maydell, who must have better ideas than me on building on Mac.
>
> On Mon, 05/02 20:47, Christopher Friedt wrote:
>>
>> Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build 
>> for a few reasons.
>>
>> One of those reasons is that Apple's ld (at least ld64) does not properly 
>> process archive files created with ar (even Apple's ar).
>>
>> After some RTFM'ing, I came upon this tidbit, which is unfortunate. Luckily, 
>> autotools packages are not broken.
>>
>> "Libtool with -static is intended to replace ar(5) and ranlib."
>> http://www.manpages.info/macosx/libtool.1.html
>>
>> In any case, this change takes Apple's recommendations into account and 
>> allows Qemu to build on Mac OS X El Capitan.
>>
>> Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
>> ---
>>  rules.mak | 4 
>>  1 file changed, 4 insertions(+)
>>
>
>> diff --git a/rules.mak b/rules.mak
>> index d1ff311..44421af 100644
>> --- a/rules.mak
>> +++ b/rules.mak
>> @@ -105,7 +105,11 @@ modules:
>>   $(call LINK,$(filter %.o %.a %.mo, $^))
>>
>>  %.a:
>> +ifeq ($(shell uname),Darwin)
>
> I think you can use "ifdef CONFIG_DARWIN" here.

Good suggestion. I missed that entirely.

>> + $(call quiet-command,rm -f $@ && libtool -static -o $@ $^,"  libtool   
>>  $(TARGET_DIR)$@")
>
> Is libtool always available on Mac OS X? If not, we may need to add the
> detection to ./configure.

Apple's libtool should be installed with their command line tools, at
least as far back as Snow Leopard.

Re: [Qemu-devel] [PATCH 1/2] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

On Mon, May 2, 2016 at 8:53 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 3 May 2016 at 01:47, Christopher Friedt <chrisfri...@gmail.com> wrote:
>>
>> Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails
>> to build for a few reasons.
>
> I guess this is a new-in-ElCapitan thing? I run Yosemite, which is
> fine.

I think you're partially correct, although the information on the man page dates
back to at least Snow Leopard (10.6.2) [1], so Apple has preferred the
libtool method for a very long time.

It's possible that it only finally broke in El Capitan.

[1] http://www.unix.com/man-page/osx/1/libtool/

[Qemu-devel] [PATCH 1/2] [RESENT-INLINE] Use libtool instead of ar to create static libraries on Darwin.

[Christopher Friedt]

Currently, at least on Mac OS X 10.11.4 (El Capitan), Qemu fails to build for a 
few reasons.

One of those reasons is that Apple's ld (at least ld64) does not properly 
process archive files created with ar (even Apple's ar).

After some RTFM'ing, I came upon this tidbit, which is unfortunate. Luckily, 
autotools packages are not broken.

"Libtool with -static is intended to replace ar(5) and ranlib."
http://www.manpages.info/macosx/libtool.1.html

In any case, this change takes Apple's recommendations into account and allows 
Qemu to build on Mac OS X El Capitan.

Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
---
 rules.mak | 4 
 1 file changed, 4 insertions(+)

diff --git a/rules.mak b/rules.mak
index d1ff311..44421af 100644
--- a/rules.mak
+++ b/rules.mak
@@ -105,7 +105,11 @@ modules:
$(call LINK,$(filter %.o %.a %.mo, $^))
 
 %.a:
+ifeq ($(shell uname),Darwin)
+   $(call quiet-command,rm -f $@ && libtool -static -o $@ $^,"  libtool
$(TARGET_DIR)$@")
+else
$(call quiet-command,rm -f $@ && $(AR) rcs $@ $^,"  AR
$(TARGET_DIR)$@")
+endif
 
 quiet-command = $(if $(V),$1,$(if $(2),@echo $2 && $1, @$1))
 
-- 
2.6.4 (Apple Git-63)

[Qemu-devel] [PATCH 2/2] [RESENT-INLINE] Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy link

[Christopher Friedt]

The file ivshmem.c unconditionally references event_notifier_init_fd() in 
util/event_notifier-posix.c, even if CONFIG_EVENTFD is not defined. On 
platforms where CONFIG_POSIX is defined, but CONFIG_EVENTFD is not defined, 
that results in an undefined symbol referenced from ivshmem.c and the link 
fails. That applies to Mac OS X, but possibly other BSD-based distros.

Note: there is nothing specific to eventfd inside and event_notifier_init() 
also fails unconditionally if CONFIG_EVENTFD is not defined.
Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
---
 util/event_notifier-posix.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/util/event_notifier-posix.c b/util/event_notifier-posix.c
index c1f0d79..c9bb34d 100644
--- a/util/event_notifier-posix.c
+++ b/util/event_notifier-posix.c
@@ -21,7 +21,6 @@
 #include 
 #endif
 
-#ifdef CONFIG_EVENTFD
 /*
  * Initialize @e with existing file descriptor @fd.
  * @fd must be a genuine eventfd object, emulation with pipe won't do.
@@ -31,7 +30,6 @@ void event_notifier_init_fd(EventNotifier *e, int fd)
 e->rfd = fd;
 e->wfd = fd;
 }
-#endif
 
 int event_notifier_init(EventNotifier *e, int active)
 {
-- 
2.6.4 (Apple Git-63)

[Qemu-devel] [PATCH 0/2][RESENT-INLINE] Resolve link errors on Mac OS X

[Christopher Friedt]

Hi list,

I recently tried to build Qemu on Mac and ran into a couple of trivial issues
that I've provided patches for. I suppose that normally people just use
'brew install qemu', but there is really no reason that it can't be built from
source, particularly for those modifying Qemu regularly.

In any case, the first change moves to using 'libtool -static' to create
libraries on Mac OS X. If one attempts to use ar and ranlib, then the final
link will fail with error messages resembling the following:

  ld: warning: ignoring file libqemuutil.a, file was built for archive which
  is not the architecture being linked (x86_64): libqemuutil.a
  Undefined symbols for architecture x86_64:
  ...

Notice ld (Apple's ld64) presumes the static library is a relocatable with
architecture 'archive' rather than x86_64, in this case.

A similar fix is required for dtc - again quite trivial, but I can provide that 
if necessary.

The second patch removes the preprocessor conditional around the function
event_notifier_init_fd() in util/event_notifier-posix.c so that the link does
not fail on systems where CONFIG_POSIX is defined but CONFIG_EVENTFD is not
(such as under Mac OS X).

There is more information in each of the commits that follows.

Please feel free to comment.

Cheers,

C

Christopher Friedt (2):
  Use libtool instead of ar to create static libraries on Darwin.
  Remove unnecessary CONFIG_EVENTFD preprocessor conditional to satisfy
link

 rules.mak   | 4 
 util/event_notifier-posix.c | 2 --
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.6.4 (Apple Git-63)

[Qemu-devel] mac development? cannot step with gdb

[Christopher Friedt]

Hi list,

I'm trying to implement some features in vmware_vga.c, so that I can
use a more recent vgabios-vmware.bin. My environment is Mac El Capitan
using clang and gdb. Perhaps using clang & gdb is my fatal flaw, but
I'm just not accustomed to using lldb yet.

Are there any others who primarily develop Qemu on a Mac? If so, what
debug environment are you using?

In any case, the specific issue I'm running into is this: Although
Qemu builds and runs well, and I can step through all parts of a
simple (or not simple)  'hello world' application, I am unable to step
through vmsvga_init() or any other function inside vmware_vga.c . I
can set a breakpoint and stop in those functions, but can't _step_
through any actual code. I wonder if that's the result of Mac + static
function + barf() or something..


Thread 1 hit Breakpoint 1, 0x000100217d14 in vmsvga_init ()
(gdb) s
Single stepping until exit from function vmsvga_init,
which has no line number information.
0x000100217b52 in pci_vmsvga_realize ()


Many devs on the list are undoubtedly familiar with the history of Mac
related debugging troubles..

Oh, the evil, fruity, walled-garden!!

I guess I may as well just try out lldb.

C

Re: [Qemu-devel] [PATCH v2 08/26] armv7m: rewrite NVIC

[Christopher Friedt]

On Wed, Dec 2, 2015 at 7:18 PM, Michael Davidsaver
 wrote:
> Expand the NVIC to fully support -M priorities and masking.

Wow - this whole patch series is quite impressive. I was just about to
start doing a MemManage implementation when I saw this and some
previous posts on the topic.

Michael, I've previously written an emulator that covers v6M & v7M
(unfortunately no DSP or floating point - yet). Do you have a branch
in github that I could track?

I'm sure I could be of some use for feedback and to help get your
patchset accepted.

Thanks,

C

Re: [Qemu-devel] [PATCH v2 08/26] armv7m: rewrite NVIC

[Christopher Friedt]

On Sat, Dec 19, 2015 at 2:08 PM, Christopher Friedt
<chrisfri...@gmail.com> wrote:
> On Wed, Dec 2, 2015 at 7:18 PM, Michael Davidsaver
> <mdavidsa...@gmail.com> wrote:
>> Expand the NVIC to fully support -M priorities and masking.
>
> Wow - this whole patch series is quite impressive. I was just about to
> start doing a MemManage implementation when I saw this and some
> previous posts on the topic.
>
> Michael, I've previously written an emulator that covers v6M & v7M
> (unfortunately no DSP or floating point - yet). Do you have a branch
> in github that I could track?
>
> I'm sure I could be of some use for feedback and to help get your
> patchset accepted.

I think I found your github tree already: https://github.com/mdavidsaver/qemu

Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

Just to update everyone, there is a thread on gdb-patches here [1]
that is awaiting consensus before a patch is submitted that we may
pull into qemu.

[1] https://goo.gl/FyUvQu

Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

On Mon, Dec 14, 2015 at 10:56 AM, Alex Bennée  wrote:
> IIRC last time I played with this when adding aarch64 system registers
> for debugging is the number is irrelevant to gdb, its all dependant on
> what the stub sends. As long as the coprocessor get/set functions agree
> on the order with the xml everything should be fine.

That's right - the question isn't really how get the two to
communicate, but really which registers numbers to choose and how to
choose them in such a way that it doesn't make anyone angry :-)

And Peter is likely right that we should ask the gdb folks input -
Peter, do you have someone particular in mind?

Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

On Mon, Dec 14, 2015 at 3:31 AM, Peter Maydell  wrote:
> This patch seems to be creating a completely new method of
> constructing the XML to send to gdb. Is it really not possible
> to do this using the existing mechanisms we have for selecting
> XML to send to gdb and handling the registers it implies?

Hehehe... I only just saw the gdb-xml/ directory. I'll create a
gdb-xml/arm-cortex-m-core.xml then, and refactor some of the remaining
lines of code.

Thanks for the feedback ;-)

Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

On Mon, Dec 14, 2015 at 8:16 AM, Christopher Friedt
<chrisfri...@gmail.com> wrote:
> On Mon, Dec 14, 2015 at 8:14 AM, Peter Maydell <peter.mayd...@linaro.org> 
> wrote:
>> Note that our XML files are from gdb itself, so you should start
>> by checking whether gdb has a suitable Cortex-M xml file.
>
> They do indeed. Thanks for the tip.

binutils-gdb arm-m-profile.xml: https://goo.gl/hpTye8
openocd armv7m.c: http://goo.gl/FFn56X

There are 2 (major) differences from what I've seen:

1) xpsr is regnum 25 instead of 16 (what OpenOCD uses), and I'm fine with that.
2) binutils-gdb does not specify anything for the
org.gnu.gdb.arm.m-system group of core registers in any xml file.

It also seems very clear that the binutils people and the openocd
people have diverged at some point in their assignment of regnum
values; in openocd, the registers are mostly all consecutive with
moderate reuse between cores, whereas in binutils-gdb, their are
occasional gaps and extensive reuse between cores. The differences
seem primarily technical, but it's unclear as to why binutils-gdb does
*not* include the m-system group of core registers.

The m-system group of core registers are *incredibly* useful, but I'm
also inclined not to clobber binutils-gdb's register numbering
convention.

I think it would be most ideal to append the crucial m-system
information directly [1] in arm-m-profile.xml from binutils-gdb (or
possibly declare it as an include [2]):


  
  
  
  
  
  


However, if the worry there is that it diverges from binutils-gdb,
then the next best solution would be to create a separate
arm-m-system.xml, and to append that to the cpu->gdb_reg linked list
in cortex_m3_initfn(), cortex_m4_initfn(), and any other m's [3].

Which solution would work best for qemu?

C

Re: [Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

On Mon, Dec 14, 2015 at 8:14 AM, Peter Maydell  wrote:
> Note that our XML files are from gdb itself, so you should start
> by checking whether gdb has a suitable Cortex-M xml file.

They do indeed. Thanks for the tip.

[Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

* allow overriding the default xml descriptor with gdb_xml_descriptor()
* read cortex-m registers using arm_cortexm_gdb_read_register()
* write cortex-m registers using arm_cortexm_gdb_write_register()
* correct the number of cortex-m core regs to 23

Signed-off-by: Christopher Friedt <chrisfri...@gmail.com>
---
 gdbstub.c|  29 ---
 include/qom/cpu.h|   1 +
 target-arm/cpu-qom.h |   4 +
 target-arm/cpu.c |   5 +-
 target-arm/gdbstub.c | 215 +++
 5 files changed, 241 insertions(+), 13 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index 9c29aa0..4684a4b 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -540,19 +540,24 @@ static const char *get_feature_xml(const char *p, const 
char **newp,
 GDBRegisterState *r;
 CPUState *cpu = first_cpu;
 
-snprintf(target_xml, sizeof(target_xml),
- ""
- ""
- ""
- "",
- cc->gdb_core_xml_file);
-
-for (r = cpu->gdb_regs; r; r = r->next) {
-pstrcat(target_xml, sizeof(target_xml), "xml);
-pstrcat(target_xml, sizeof(target_xml), "\"/>");
+if (cc->gdb_xml_descriptor) {
+cc->gdb_xml_descriptor(cpu, target_xml, sizeof(target_xml));
+} else {
+snprintf(target_xml, sizeof(target_xml),
+ ""
+ ""
+ ""
+ "",
+ cc->gdb_core_xml_file);
+
+for (r = cpu->gdb_regs; r; r = r->next) {
+pstrcat(target_xml, sizeof(target_xml),
+"xml);
+pstrcat(target_xml, sizeof(target_xml), "\"/>");
+}
+pstrcat(target_xml, sizeof(target_xml), "");
 }
-pstrcat(target_xml, sizeof(target_xml), "");
 }
 return target_xml;
 }
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 51a1323..7b8d875 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -152,6 +152,7 @@ typedef struct CPUClass {
 int (*handle_mmu_fault)(CPUState *cpu, vaddr address, int rw,
 int mmu_index);
 hwaddr (*get_phys_page_debug)(CPUState *cpu, vaddr addr);
+int (*gdb_xml_descriptor)(CPUState *cpu, char *buf, size_t len);
 int (*gdb_read_register)(CPUState *cpu, uint8_t *buf, int reg);
 int (*gdb_write_register)(CPUState *cpu, uint8_t *buf, int reg);
 void (*debug_excp_handler)(CPUState *cpu);
diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
index 25fb1ce..eafae6b 100644
--- a/target-arm/cpu-qom.h
+++ b/target-arm/cpu-qom.h
@@ -221,6 +221,10 @@ hwaddr arm_cpu_get_phys_page_debug(CPUState *cpu, vaddr 
addr);
 int arm_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
 int arm_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
 
+int arm_cortexm_gdb_xml_descriptor(CPUState *cpu, char *buf, size_t len);
+int arm_cortexm_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
+int arm_cortexm_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
+
 /* Callback functions for the generic timer's timers. */
 void arm_gt_ptimer_cb(void *opaque);
 void arm_gt_vtimer_cb(void *opaque);
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 30739fc..e56b77a 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -553,7 +553,6 @@ static void arm_cpu_post_init(Object *obj)
  _abort);
 }
 }
-
 }
 
 static void arm_cpu_finalizefn(Object *obj)
@@ -910,6 +909,10 @@ static void arm_v7m_class_init(ObjectClass *oc, void *data)
 #endif
 
 cc->cpu_exec_interrupt = arm_v7m_cpu_exec_interrupt;
+cc->gdb_num_core_regs = 23;
+cc->gdb_xml_descriptor = arm_cortexm_gdb_xml_descriptor;
+cc->gdb_read_register = arm_cortexm_gdb_read_register;
+cc->gdb_write_register = arm_cortexm_gdb_write_register;
 }
 
 static const ARMCPRegInfo cortexr5_cp_reginfo[] = {
diff --git a/target-arm/gdbstub.c b/target-arm/gdbstub.c
index 1c34396..eb39757 100644
--- a/target-arm/gdbstub.c
+++ b/target-arm/gdbstub.c
@@ -3,6 +3,7 @@
  *
  * Copyright (c) 2003-2005 Fabrice Bellard
  * Copyright (c) 2013 SUSE LINUX Products GmbH
+ * Copyright (c) 2015 Christopher Friedt
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -100,3 +101,217 @@ int arm_cpu_gdb_write_register(CPUState *cs, uint8_t 
*mem_buf, int n)
 /* Unknown register.  */
 return 0;
 }
+
+enum cm_gdb_regnr {
+R0, R1, R2, R3,
+R4, R5, R6, R7,
+R8, R9, R10, R11,
+R12, SP, LR, PC,
+XPSR, MSP, PSP, PRIMASK,
+BASEPR

[Qemu-devel] [RFC] qemu-system-arm: cortex-m gdb registers

[Christopher Friedt]

At least for Cortex-M3 devices (but also M0, M0+, M4, ...), while
JTAG debugging using OpenOCD's built-in GDB server, the general purpose
register layout (i.e. `info reg' in GDB) should contain slightly more than
the usual ARM core registers.

The non-addressable core registers that appear in OpenOCD's listing are:

r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp (r13), lr (r14),
pc (r15), xpsr, primask, basepri, faultmask, and control.

These registers are well documented in the ARMv7M Architecture Reference
Manual.

This change addes preliminary support for those registers via a custom 
qXfer:features:read+ and XML response that follows the GNU convention
documented here [1] for org.gnu.gdb.arm.m-profile and
org.gnu.gdb.arm.m-system.

[1] https://goo.gl/NMxlC5

The default behaviour for non-cortex-m will be to mimic the original ARM
behaviour of referring the GDB client to an .

A simple test environment for this patch is to compile and link the following
assembly fragment:

.syntax unified
.cpu cortex-m3

.section .interp
.word 0x2002
.word 0x9

.text

.global _start
.thumb
.thumb_func
.type _start, %function
_start:
b _start
.size _start, .-_start

Using the command below:

arm-none-eabi-gcc -g -O0 -mthumb -march=armv7-m -Wl,-Ttext-segment,0 \
-static -nostartfiles -o foo foo.S

Launch the resulting binary with qemu:

qemu-system-arm -S -s -M netduino2 -nographic -kernel foo

Run gdb, attaching to the qemu's GDB server:

arm-none-eabi-gdb foo
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x in _start ()
(gdb) info all-registers
r0 0x0  0
r1 0x0  0
r2 0x0  0
r3 0x0  0
r4 0x0  0
r5 0x0  0
r6 0x0  0
r7 0x0  0
r8 0x0  0
r9 0x0  0
r100x0  0
r110x0  0
r120x0  0
sp 0xbffef7fc   0xbffef7fc
lr 0x0  0
pc 0x0  0x0 <_start>
xpsr   0x4000   1073741824
msp0xbffef7fc   0xbffef7fc
psp0x0  0x0 <_start>
primask0x0  0
basepri0x0  0
faultmask  0x1  1
control0x0  0

The changes have been tested with other firmware images and also via Eclipse
Mars.

Christopher Friedt (1):
  qemu-system-arm: cortex-m gdb registers

 gdbstub.c|  29 ---
 include/qom/cpu.h|   1 +
 target-arm/cpu-qom.h |   4 +
 target-arm/cpu.c |   5 +-
 target-arm/gdbstub.c | 215 +++
 5 files changed, 241 insertions(+), 13 deletions(-)

-- 
2.5.4 (Apple Git-61)

[Qemu-devel] patch to fix EXC_BAD_ACCESS on Mac OS X

[Christopher Friedt]

Hi folks,

I've been digging through a bunch of runtime errors in OS X. One of
them was an EXC_BAD_ACCESS (segfault) caused by some code in
main-loop.c that accessed uninitialized stack variables. Please see
the attached patch. The problem still exists in the master branch of
the git repository.

I've also been running into a failed assertion which causes SIGABRT

Assertion failed: (QLIST_EMPTY(bs-tracked_requests)), function
bdrv_drain_all, file block.c, line 1220.

I haven't yet found out the root cause of it, but it sounds like
another struct that isn't properly zero'd. Will keep working on it.

C


qemu-1.3.0_to_gitmaster-fix-exc-bad-access-in-main-loop.patch
Description: Binary data

Re: [Qemu-devel] patch to fix EXC_BAD_ACCESS on Mac OS X

[Christopher Friedt]

Actually, disabling assertions, qemu appears to enter an infinite loop
where the above assertion fails. Boo.

On Fri, Feb 1, 2013 at 7:14 AM, Christopher Friedt
chrisfri...@gmail.com wrote:
 Hi folks,

 I've been digging through a bunch of runtime errors in OS X. One of
 them was an EXC_BAD_ACCESS (segfault) caused by some code in
 main-loop.c that accessed uninitialized stack variables. Please see
 the attached patch. The problem still exists in the master branch of
 the git repository.

 I've also been running into a failed assertion which causes SIGABRT

 Assertion failed: (QLIST_EMPTY(bs-tracked_requests)), function
 bdrv_drain_all, file block.c, line 1220.

 I haven't yet found out the root cause of it, but it sounds like
 another struct that isn't properly zero'd. Will keep working on it.

 C

Re: [Qemu-devel] patch to fix EXC_BAD_ACCESS on Mac OS X

[Christopher Friedt]

Hi Peter,

On Fri, Feb 1, 2013 at 1:01 PM, Peter Maydell peter.mayd...@linaro.org wrote:
 OSX generally works for me, with some caveats:
  * current master doesn't compile because of a recent patch
related to ffsl; this should be fixed soon I hope.

I'll have to check out master again. Currently I'm using 1.3.0, but
the ffsl issue
doesn't seem like it would be hard to fix at all.

  * running under gdb seems to cause failures which don't
happen running not under a debugger. In particular it
seems that sigwait() is broken by gdb (?!?) in a way that
means it can return zero without setting *sig. A lack
of error checking on the return value from sigaction()
in sigfd_handler() means we then go off into the weeds.

Funny that you mention Mac OS X gdb, because I only ever did see a
segfault when I was debugging. I'm glad I wasn't the only one seeing
something unexpected. I'm sure Apple just markets that as a feature.

  * for some reason sending qemu a SIGTERM doesn't cause us
to terminate. I've had difficulty tracking down the issues
due to the aforementioned tendency of macos gdb to bork
signalhandling of the debuggee.

Yea, SIGKILL seems to work well though ;-)

 PS: you might like to read our guidelines for patch
 submission; your patch failed several of them...
 http://wiki.qemu.org/Contribute/SubmitAPatch

I believe it - I posted it quickly before running out the door this morning.

Is there a more-or-less reliable build that's working for Mac?

C

Re: [Qemu-devel] disk images driver geometry

[Christopher Friedt]

Anthony Liguori wrote:
I have no idea what you're talking about.  QEMU doesn't care whether you 
use a physical disk or a file.  It handles geometry the same way.


Is there a concrete example that doesn't work that you think should?


Yes, a simple example is running CentOS after a typical install from a 
hard disk image.


If Qemu is started with the installation cdrom (-cdrom CentOS-1of4*.iso) 
the installation creates several partitions on the virtual disk, 
including /boot, and a logical disk containing /. The first 512 Bytes of 
the disk image are assumed to be the MBR of the disk, which is where the 
installation will write the boot loader.


After installation, qemu is started with

qemu -hda centos.img -boot c

and it hangs after saying 'booting from hard disk'

If anyone knows a way to work around this, please don't hesitate to 
offer a suggestion.


~/Chris

[Qemu-devel] disk images driver geometry

[Christopher Friedt]

Hi everyone,

has there been any work done in the last few months towards hard disk 
geometry, so that partition tables / mbr's in raw hard disk files can be 
stored for later use?


That's something that would be tremendously useful with the -hda option, 
so that one could use a file for a virtual disk and expect qemu to 
recognize the partition information from it. Usually if one does a 
typical install with a linux distro, the linux install will format the 
main hard disk to have 3 partitions (boot,root,swap), but if it's just a 
file then that partition / mbr info isn't really recognized by qemu.


I've been out of the loop w/ what's happening on the bleeding edge with 
qemu for a few months, so I thought I'd just ask here.


~/Chris

Re: [Qemu-devel] usb_host: only one interface supported

[Christopher Friedt]

I just applied the patch located in this thread:

http://lists.gnu.org/archive/html/qemu-devel/2007-06/msg00331.html

and it worked!

Thanks Arnaud

Christopher Friedt wrote:

Hi everyone,

I'm trying to plug in a usb device (Motorola L2 phone, with micro usb 
connector).


When I try to add it using the qemu console,

usb_add host:22b8:4902

I get the response usb_host: only one interface supported in the 
standard output / error.


What does this mean exactly? Is there some way I could patch my source 
code to allow this to work?


I sort of got the impression that maybe the kernel had 'claimed' this 
device and therefore couldn't allow another app to address it directly. 
Is that the case?


I also tried removing / adding the cdc_acm module and running it that 
way as a serial console, but for me (running motorola software update) 
it seems not to work



Any suggestions?

~/Chris

[Qemu-devel] root userid remapping? ... no UID / GID variables set in NFS root?

[Christopher Friedt]

Hi everyone,

I've just gotten qemu emulating an arm system on my laptop, which I'm 
hoping to use for cross-compilation. I don't have a disk image to use 
(is there any way to create a disk image from a directory tree??), so 
I'm using NFS instead.


The strange thing is, is that although I specify no_root_squash in my 
/etc/exports (and I've been using NFS for quite a long time successfully 
with other machines), only when I'm using Qemu does the user id of the 
'init' process [0] get remapped to some completely absurd value of 
4294967295.


Has anyone heard of this happening before?

Thanks in advance for any and all responses.

~/Chris