[Qemu-devel] Patch1 for Mips64 usermode
*commands for patch apply*
git apply --ignore-whitespace --ignore-space-change --check ~/patch1
git am --ignore-whitespace --ignore-space-change ~/patch1
*Patch*
>From e96e20e50cada1c9e1b65de5925281cdd5659746 Mon Sep 17 00:00:00 2001
From: Ehsan-ul-Haq & Khansa Butt
Date: Sat, 9 Apr 2011 10:51:22 +0500
Subject: [PATCH 1/2] Support for MIPS64 user mode emulation
Signed-off-by: Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed, Khansa Butt <
kha...@kics.edu.pk>
---
configure |1 +
default-configs/mips64-linux-user.mak |1 +
linux-user/elfload.c |2 +-
linux-user/main.c | 29 +++--
linux-user/mips64/syscall.h |3 +++
linux-user/signal.c |3 ++-
target-mips/translate.c |1 +
7 files changed, 36 insertions(+), 4 deletions(-)
create mode 100644 default-configs/mips64-linux-user.mak
diff --git a/configure b/configure
index ae97e11..d1f7867 100755
--- a/configure
+++ b/configure
@@ -1039,6 +1039,7 @@ m68k-linux-user \
microblaze-linux-user \
microblazeel-linux-user \
mips-linux-user \
+mips64-linux-user \
mipsel-linux-user \
ppc-linux-user \
ppc64-linux-user \
diff --git a/default-configs/mips64-linux-user.mak
b/default-configs/mips64-linux-user.mak
new file mode 100644
index 000..1598bfc
--- /dev/null
+++ b/default-configs/mips64-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mips64-linux-user
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index fe5410e..2832a33 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1384,7 +1384,7 @@ static void load_elf_image(const char *image_name, int
image_fd,
vaddr_po = TARGET_ELF_PAGEOFFSET(vaddr);
vaddr_ps = TARGET_ELF_PAGESTART(vaddr);
-error = target_mmap(vaddr_ps, eppnt->p_filesz + vaddr_po,
+error = target_mmap(vaddr_ps, eppnt->p_memsz + vaddr_po,
elf_prot, MAP_PRIVATE | MAP_FIXED,
image_fd, eppnt->p_offset - vaddr_po);
if (error == -1) {
diff --git a/linux-user/main.c b/linux-user/main.c
index e651bfd..a7f4955 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1937,6 +1937,14 @@ static int do_store_exclusive(CPUMIPSState *env)
int d;
addr = env->lladdr;
+#if defined(TARGET_MIPS64)
+/* For MIPS64 on 32 bit host there is a need to make
+* the page accessible to which the above 'addr' is belonged */
+#if HOST_LONG_BITS == 32
+int flag = PAGE_VALID | PAGE_READ | PAGE_WRITE | PAGE_WRITE_ORG;
+page_set_flags(addr, addr + 4096, flag);
+#endif
+#endif
page_addr = addr & TARGET_PAGE_MASK;
start_exclusive();
mmap_lock();
@@ -1978,7 +1986,8 @@ static int do_store_exclusive(CPUMIPSState *env)
void cpu_loop(CPUMIPSState *env)
{
target_siginfo_t info;
-int trapnr, ret;
+int trapnr;
+abi_long ret;
unsigned int syscall_num;
for(;;) {
@@ -1987,7 +1996,11 @@ void cpu_loop(CPUMIPSState *env)
cpu_exec_end(env);
switch(trapnr) {
case EXCP_SYSCALL:
+#if defined(TARGET_MIPS64)
+syscall_num = env->active_tc.gpr[2] - 5000;
+#else
syscall_num = env->active_tc.gpr[2] - 4000;
+#endif
env->active_tc.PC += 4;
if (syscall_num >= sizeof(mips_syscall_args)) {
ret = -ENOSYS;
@@ -2008,12 +2021,22 @@ void cpu_loop(CPUMIPSState *env)
default:
break;
}
+#if defined(TARGET_MIPS64)
+ret = do_syscall(env, env->active_tc.gpr[2],
+ env->active_tc.gpr[4],
+ env->active_tc.gpr[5],
+ env->active_tc.gpr[6],
+ env->active_tc.gpr[7],
+ env->active_tc.gpr[8],
+ env->active_tc.gpr[9]);
+#else
ret = do_syscall(env, env->active_tc.gpr[2],
env->active_tc.gpr[4],
env->active_tc.gpr[5],
env->active_tc.gpr[6],
env->active_tc.gpr[7],
arg5, arg6/*, arg7, arg8*/);
+#endif
}
if (ret == -TARGET_QEMU_ESIGRETURN) {
/* Returning from a successful sigreturn syscall.
@@ -2935,7 +2958,9 @@ int main(int argc, char **argv, char **envp)
#endif
#elif defined(TARGET_MIPS)
#if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
-cpu_model = "20Kc";
+/* we use this model so that we can decode MIPS64r2
+ reserved instruction */
+cpu_model = "MIPS64R2-generic";
#else
cpu_model = "24Kf";
#endif
diff --git a/linux-user/mips64/syscall.h b/linux-user/mips64/syscall.h
index 668a2b9..ec65653 100644
--- a/linux-user/mips64/syscall
[Qemu-devel] Re: [PATCH] ioapic: when switches to level trigger mode, interrupts raised repeatedly.
On 2011-04-04 04:15, Isaku Yamahata wrote:
> On Mon, Apr 04, 2011 at 08:42:07AM +0900, Isaku Yamahata wrote:
>> > Thank you for applying. But I found that the patch is wrong and
>> > I'm preparing the new one. Can you please revert it?
> Here is the corrected patch. The first wrong patch clears the interrupts
> bit unconditionally. Which caused losing interrupt.
>
> From 5ed177d35ab14f3b070a0eba2c49400279a3a14b Mon Sep 17 00:00:00 2001
> Message-Id:
> <5ed177d35ab14f3b070a0eba2c49400279a3a14b.1301883258.git.yamah...@valinux.co.jp>
> In-Reply-To:
> References:
> From: Isaku Yamahata
> Date: Wed, 16 Mar 2011 14:00:13 +0900
> Subject: [PATCH 01/30] ioapic: when switches to level trigger mode,
> interrupts raised repeatedly.
>
> - the trigger mode is edge at first by reset.
> - During initializatoin, the interrupt is raised as edge which is masked.
> The corresponding bit of irr is set.
...and that is the actual problem. The spec says: "Interrupt Mask—R/W.
When this bit is 1, the interrupt signal is masked. Edge-sensitive
interrupts signaled on a masked interrupt pin are ignored (i.e., not
delivered or held pending)."
So this should do the trick in a correct way (untested, please
validate):
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 569327d..6663f41 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -161,7 +161,7 @@ static void ioapic_set_irq(void *opaque, int vector, int
level)
}
} else {
/* edge triggered */
-if (level) {
+if (level && !(entry & IOAPIC_LVT_MASKED)) {
s->irr |= mask;
ioapic_service(s);
}
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] MIPS64 user mode emulation Patch
Please see the online comments highlighted in red.
I'll be sending corrected Patches to the mailing list.
On Wed, Mar 30, 2011 at 9:38 PM, Nathan Froyd wrote:
> On Sat, Mar 26, 2011 at 11:58:37AM +0500, Khansa Butt wrote:
> > Subject: [PATCH] MIPS64 user mode emulation in QEMU
> > This patch adds support for Cavium Network's
> > Octeon 57XX user mode instructions. Octeon
> > 57xx is based on MIPS64. So this patch is
> > the first MIPS64 User Mode Emulation in QEMU
> > This is the team(Khansa Butt, Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed)
> > work of HPCNL Lab at KICS-UET Lahore.
>
> Thanks for doing this. As already noted, this patch should be split
> into at least two patches: one to add Octeon-specific instructions in
> target-mips/ and one adding the necessary linux-user bits.
>
> > +extern int TARGET_OCTEON;
>
> I don't think a global like this is the right way to go. Perhaps the
> elfload.c code should set a flag in image_info , which can then be used
> to set a flag in CPUMIPSState later on.
>
A variable is declared in image_info to set a flag in CPUMIPSState and
discarded a global variable
@@ -51,6 +51,7 @@ struct image_info {
abi_ulong arg_start;
abi_ulong arg_end;
int personality;
+ int elf_arch;
>
> If we must use a global variable, it should be declared in
> target-mips/cpu.h.
>
> > @@ -2013,7 +2024,8 @@ void cpu_loop(CPUMIPSState *env)
> > env->active_tc.gpr[5],
> > env->active_tc.gpr[6],
> > env->active_tc.gpr[7],
> > - arg5, arg6/*, arg7, arg8*/);
> > + env->active_tc.gpr[8],
> > + env->active_tc.gpr[9]/*, arg7, arg8*/);
> > }
> > if (ret == -TARGET_QEMU_ESIGRETURN) {
> > /* Returning from a successful sigreturn syscall.
>
> This change breaks O32 binaries; it needs to be done in a different way.
>
The above line has been changed with following code snippet
+#if defined(TARGET_MIPS64)
+ret = do_syscall(env, env->active_tc.gpr[2],
+ env->active_tc.gpr[4],
+ env->active_tc.gpr[5],
+ env->active_tc.gpr[6],
+ env->active_tc.gpr[7],
+ env->active_tc.gpr[8],
+ env->active_tc.gpr[9]);
+#else
ret = do_syscall(env, env->active_tc.gpr[2],
env->active_tc.gpr[4],
env->active_tc.gpr[5],
env->active_tc.gpr[6],
env->active_tc.gpr[7],
arg5, arg6/*, arg7, arg8*/);
+#endif
> > diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> > index 499c4d7..47fef05 100644
> > --- a/linux-user/syscall.c
> > +++ b/linux-user/syscall.c
> > @@ -7195,6 +7195,8 @@ abi_long do_syscall(void *cpu_env, int num,
> abi_long
> > arg1,
> > case TARGET_NR_set_thread_area:
> > #if defined(TARGET_MIPS)
> >((CPUMIPSState *) cpu_env)->tls_value = arg1;
> > + /*tls entry is moved to k0 so that this can be used later*/
> > + ((CPUMIPSState *) cpu_env)->active_tc.gpr[26] = arg1;
> >ret = 0;
> >break;
> > #elif defined(TARGET_CRIS)
>
> I believe this is only correct for Octeon binaries; it's not how the
> rest of the MIPS world works. It therefore needs to be conditional on
> Octeon-ness.
>
> The above thing has been made octeon specific
> > --- a/target-mips/cpu.h
> > +++ b/target-mips/cpu.h
> > @@ -140,6 +140,20 @@ typedef struct mips_def_t mips_def_t;
> > #define MIPS_FPU_MAX 1
> > #define MIPS_DSP_ACC 4
> >
> > +typedef struct cavium_mul cavium_mul;
> > +struct cavium_mul {
> > + target_ulong MPL0;
> > + target_ulong MPL1;
> > + target_ulong MPL2;
> > + target_ulong P0;
> > + target_ulong P1;
> > + target_ulong P2;
> > +};
> > +typedef struct cvmctl_register cvmctl_register;
> > +struct cvmctl_register {
> > + target_ulong cvmctl;
> > +};
>
> The indentation here needs to be fixed. I don't think there's any
> reason why these need to be defined outside TCState, either.
>
Octeon register in TCState as follows
@@ -171,6 +176,15 @@ struct TCState {
target_ulong CP0_TCSchedule;
target_ulong CP0_TCScheFBack;
int32_t CP0_Debug_tcstatus;
+/* Multiplier registers for Octeon */
+target_ulong MPL0;
+target_ulong MPL1;
+target_ulong MPL2;
+target_ulong P0;
+target_ulong P1;
+target_ulong P2;
+/* Octeon specific Coprocessor 0 register */
+target_ulong cvmctl;
};
> > diff --git a/target-mips/translate.c b/target-mips/translate.c
> > index cce77be..9c3d772 100644
> > --- a/target-mips/translate.c
> > +++ b/target-mips/translate.c
> > @@ -36,6 +36,15 @@
> > #define GEN
[Qemu-devel] [PATCH 1/2] atapi: Drives can be locked without media present
Drivers are free to lock drives without any media present. Such a
condition should not result in an error condition.
See Table 341 in MMC-5 spec for details.
Signed-off-by: Amit Shah
---
hw/ide/core.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 7a407fc..8958ff2 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1390,13 +1390,8 @@ static void ide_atapi_cmd(IDEState *s)
ide_atapi_cmd_reply(s, 18, max_len);
break;
case GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL:
-if (bdrv_is_inserted(s->bs)) {
-bdrv_set_locked(s->bs, packet[4] & 1);
-ide_atapi_cmd_ok(s);
-} else {
-ide_atapi_cmd_error(s, SENSE_NOT_READY,
-ASC_MEDIUM_NOT_PRESENT);
-}
+bdrv_set_locked(s->bs, packet[4] & 1);
+ide_atapi_cmd_ok(s);
break;
case GPCMD_READ_10:
case GPCMD_READ_12:
--
1.7.4.2
[Qemu-devel] [PATCH 2/2] atapi: Report correct errors on guest eject request
Table 629 of the MMC-5 spec mentions two different error conditions when
a CDROM eject is requested: a) while a disc is inserted and b) while a
disc is not inserted.
Ensure we return the appropriate error for the present condition of the
drive and disc status.
Signed-off-by: Amit Shah
---
hw/ide/core.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 8958ff2..b8b78bb 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1464,7 +1464,7 @@ static void ide_atapi_cmd(IDEState *s)
break;
case GPCMD_START_STOP_UNIT:
{
-int start, eject, err = 0;
+int start, eject, sense, err = 0;
start = packet[4] & 1;
eject = (packet[4] >> 1) & 1;
@@ -1477,7 +1477,11 @@ static void ide_atapi_cmd(IDEState *s)
ide_atapi_cmd_ok(s);
break;
case -EBUSY:
-ide_atapi_cmd_error(s, SENSE_NOT_READY,
+sense = SENSE_NOT_READY;
+if (bdrv_is_inserted(s->bs)) {
+sense = SENSE_ILLEGAL_REQUEST;
+}
+ide_atapi_cmd_error(s, sense,
ASC_MEDIA_REMOVAL_PREVENTED);
break;
default:
--
1.7.4.2
[Qemu-devel] Re: Slow PXE boot in qemu.git (fast in qemu-kvm.git)
On Sat, Apr 9, 2011 at 2:25 AM, Luiz Capitulino wrote: > Hi there, > > Summary: > > - PXE boot in qemu.git (HEAD f124a41) is quite slow, more than 5 minutes. Got > the problem with e1000, virtio and rtl8139. However, pcnet *works* (it's > as fast as qemu-kvm.git) > > - PXE boot in qemu-kvm.git (HEAD df85c051) is fast, less than a minute. Tried > with e1000, virtio and rtl8139 (I don't remember if I tried with pcnet) > > I tried with qemu.git v0.13.0 in order to check if this was a regression, but > I got the same problem... > > Then I inspected qemu-kvm.git under the assumption that it could have a fix > that wasn't commited to qemu.git. Found this: > > - commit 0836b77f0f65d56d08bdeffbac25cd6d78267dc9 which is merge, works > > - commit cc015e9a5dde2f03f123357fa060acbdfcd570a4 does not work (it's slow) > > I tried a bisect, but it brakes due to gcc4 vs. gcc3 changes. Then I inspected > commits manually, and found out that commit 64d7e9a4 doesn't work, which makes > me think that the fix could be in the conflict resolution of 0836b77f, which > makes me remember that I'm late for diner, so my conclusions at this point are > not reliable :) > > Ideas? What is the test case? I tried PXE booting a 10M file with and without KVM and the results are pretty much the same with pcnet and e1000. time qemu -monitor stdio -boot n -net nic,model=e1000 -net user,tftp=.,bootfile=10M -net dump,file=foo -enable-kvm time qemu -monitor stdio -boot n -net nic,model=pcnet -net user,tftp=.,bootfile=10M -net dump,file=foo -enable-kvm time qemu -monitor stdio -boot n -net nic,model=e1000 -net user,tftp=.,bootfile=10M -net dump,file=foo time qemu -monitor stdio -boot n -net nic,model=pcnet -net user,tftp=.,bootfile=10M -net dump,file=foo All times are ~10s.
[Qemu-devel] Re: [PATCH 3/5] atapi: GESN: Spin off No Event Available handling into own function
On (Fri) 08 Apr 2011 [15:31:49], Kevin Wolf wrote: > Am 08.04.2011 09:15, schrieb Amit Shah: > > Handle GET_EVENT_STATUS_NOTIFICATION's No Event Available status in its > > own function. > > > > Also ensure the buffer the driver sent us is big enough to fill in all > > the data we have -- else just fill in as much as the buffer can hold. > > This is unnecessary and in fact none of the IDE code does this. > s->io_buffer isn't guest memory, but an internal buffer that is > allocated like this: > > s->io_buffer = qemu_memalign(2048, IDE_DMA_BUF_SECTORS*512 + 4); OK - so all the code paths will be much easier then. But by my reading of (the kernel) code, it looks as if the kernel allocates the memory and passes it on. What am I missing? > So that's more than enough for storing four bytes. ide_atapi_cmd_reply() > takes care of making only max_size bytes visible to the guest. OK - but in some cases we just do a ide_set_irq() instead of ide_atapi_cmd_reply() so what happens in that case? Amit
[Qemu-devel] Re: [PATCH 4/5] atapi: GESN: Add enums for commonly-used field types
On (Fri) 08 Apr 2011 [16:21:38], Kevin Wolf wrote:
> Am 08.04.2011 09:15, schrieb Amit Shah:
> > Instead of using magic numbers, use enums that are more descriptive of
> > the fields being used.
> >
> > Signed-off-by: Amit Shah
> > ---
> > hw/ide/core.c | 11 +--
> > 1 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index 730587e..cdc2c56 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -1118,12 +1118,19 @@ static void
> > handle_get_event_status_notification(IDEState *s,
> > uint8_t *buf,
> > const uint8_t *packet)
> > {
> > +enum cdb {
> > +polled = 1,
> > +request = 4,
> > +allocation_length_msb = 7,
> > +allocation_length_lsb = 8,
> > +control = 9,
> > +};
>
> Wouldn't it be nicer to make this a struct and just cast packet to a
> pointer to this struct? At first I didn't realize that this should be
> field offsets and I find something like packet + allocation_length_msb
> rather confusing.
Yes, indeed. It was faster for me to prototype it this way, but I
will convert it to a struct.
Amit
Re: [Qemu-devel] QEMU development for MIPS64 user mode
Please see inline comments highlighted in red. On Wed, Mar 30, 2011 at 12:04 AM, Andreas Färber wrote: > Hi, > > Am 29.03.2011 um 08:49 schrieb Khansa Butt: > > > I have added support for MIPS64 user mode emulation in QEMU and email git >> patch to the qemu-devel mailing list >> but I got no any response yet. My Patch mail has the following subject >> line >> MIPS64 user mode emulation Patch >> please verify that this patch mail is not neglected or guide me towards >> the proper way of patch submitting. >> > > You should use git-send-email to submit it (marking it as [PATCH]) so that > it can be applied with git-am, see > http://wiki.qemu.org/Contribute/SubmitAPatch and the list archives. > Also don't forget to cc the maintainer(s) - Aurelien for mips and Riku for > linux-user IIRC. > > A description of how to test it may be helpful. Maybe you have links to > mips64 binaries that work? > > Usually, the subject line of the commit message is prefixed with the topic > (linux-user) or architecture (mips). > If all the people you name contributed to this patch, you should probably > add their SoBs before yours. > The patch is rather large - is it possible to split it up into a patch > series with at least a linux-user and a (target-)mips part? > > TARGET_OCTEON looks rather uncommon to me... > > Your patch contains a "Nasty hack". Please elaborate on that - what's the > problem, do you intend to fix it later, etc. > > linux-user/mips64/syscall.h +/* Nasty hack: define a fake errno value for use by sigreturn. */ +#define TARGET_QEMU_ESIGRETURN 255 + The above lines has been copied from linux-user/mips32/syscall.h, in order to define the constant TARGET_QEMU_ESIGRETURN(as it is needed in main.c:cpu_loop()) > You simply comment out a #warning that signal handling is not implemented > for mipsn64. Why didn't you implement it? Don't you need it? > The signal handling for Mips64 is same as for other architectures. qemu handles signals which comes from a program and actual handling is done by host operating system. we follow the same convention. why this warning is generated initially? > Similarly you comment out a sign extension. Please elaborate. If it's a bug > and definitely wrong, it should be moved to its own patch, explaining what > goes wrong and fully removing it instead. > > resolved this sign extension problem > In CPUMIPSState, the surrounding struct members use lowercase characters. > > Some spaces missing after if. > > Thanks for your contribution and for taking the time to go through the > review process. > > Regards, > Andreas >
[Qemu-devel] [PATCH 1/2] Support for MIPS64 user mode emulation
>From e96e20e50cada1c9e1b65de5925281cdd5659746 Mon Sep 17 00:00:00 2001
From: Ehsan-ul-Haq & Khansa Butt
Date: Sat, 9 Apr 2011 10:51:22 +0500
Subject: [PATCH 1/2] Support for MIPS64 user mode emulation
Signed-off-by: Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed, Khansa Butt <
kha...@kics.edu.pk>
---
configure |1 +
default-configs/mips64-linux-user.mak |1 +
linux-user/elfload.c |2 +-
linux-user/main.c | 29 +++--
linux-user/mips64/syscall.h |3 +++
linux-user/signal.c |3 ++-
target-mips/translate.c |1 +
7 files changed, 36 insertions(+), 4 deletions(-)
create mode 100644 default-configs/mips64-linux-user.mak
diff --git a/configure b/configure
index ae97e11..d1f7867 100755
--- a/configure
+++ b/configure
@@ -1039,6 +1039,7 @@ m68k-linux-user \
microblaze-linux-user \
microblazeel-linux-user \
mips-linux-user \
+mips64-linux-user \
mipsel-linux-user \
ppc-linux-user \
ppc64-linux-user \
diff --git a/default-configs/mips64-linux-user.mak
b/default-configs/mips64-linux-user.mak
new file mode 100644
index 000..1598bfc
--- /dev/null
+++ b/default-configs/mips64-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mips64-linux-user
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index fe5410e..2832a33 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1384,7 +1384,7 @@ static void load_elf_image(const char *image_name, int
image_fd,
vaddr_po = TARGET_ELF_PAGEOFFSET(vaddr);
vaddr_ps = TARGET_ELF_PAGESTART(vaddr);
-error = target_mmap(vaddr_ps, eppnt->p_filesz + vaddr_po,
+error = target_mmap(vaddr_ps, eppnt->p_memsz + vaddr_po,
elf_prot, MAP_PRIVATE | MAP_FIXED,
image_fd, eppnt->p_offset - vaddr_po);
if (error == -1) {
diff --git a/linux-user/main.c b/linux-user/main.c
index e651bfd..a7f4955 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1937,6 +1937,14 @@ static int do_store_exclusive(CPUMIPSState *env)
int d;
addr = env->lladdr;
+#if defined(TARGET_MIPS64)
+/* For MIPS64 on 32 bit host there is a need to make
+* the page accessible to which the above 'addr' is belonged */
+#if HOST_LONG_BITS == 32
+int flag = PAGE_VALID | PAGE_READ | PAGE_WRITE | PAGE_WRITE_ORG;
+page_set_flags(addr, addr + 4096, flag);
+#endif
+#endif
page_addr = addr & TARGET_PAGE_MASK;
start_exclusive();
mmap_lock();
@@ -1978,7 +1986,8 @@ static int do_store_exclusive(CPUMIPSState *env)
void cpu_loop(CPUMIPSState *env)
{
target_siginfo_t info;
-int trapnr, ret;
+int trapnr;
+abi_long ret;
unsigned int syscall_num;
for(;;) {
@@ -1987,7 +1996,11 @@ void cpu_loop(CPUMIPSState *env)
cpu_exec_end(env);
switch(trapnr) {
case EXCP_SYSCALL:
+#if defined(TARGET_MIPS64)
+syscall_num = env->active_tc.gpr[2] - 5000;
+#else
syscall_num = env->active_tc.gpr[2] - 4000;
+#endif
env->active_tc.PC += 4;
if (syscall_num >= sizeof(mips_syscall_args)) {
ret = -ENOSYS;
@@ -2008,12 +2021,22 @@ void cpu_loop(CPUMIPSState *env)
default:
break;
}
+#if defined(TARGET_MIPS64)
+ret = do_syscall(env, env->active_tc.gpr[2],
+ env->active_tc.gpr[4],
+ env->active_tc.gpr[5],
+ env->active_tc.gpr[6],
+ env->active_tc.gpr[7],
+ env->active_tc.gpr[8],
+ env->active_tc.gpr[9]);
+#else
ret = do_syscall(env, env->active_tc.gpr[2],
env->active_tc.gpr[4],
env->active_tc.gpr[5],
env->active_tc.gpr[6],
env->active_tc.gpr[7],
arg5, arg6/*, arg7, arg8*/);
+#endif
}
if (ret == -TARGET_QEMU_ESIGRETURN) {
/* Returning from a successful sigreturn syscall.
@@ -2935,7 +2958,9 @@ int main(int argc, char **argv, char **envp)
#endif
#elif defined(TARGET_MIPS)
#if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
-cpu_model = "20Kc";
+/* we use this model so that we can decode MIPS64r2
+ reserved instruction */
+cpu_model = "MIPS64R2-generic";
#else
cpu_model = "24Kf";
#endif
diff --git a/linux-user/mips64/syscall.h b/linux-user/mips64/syscall.h
index 668a2b9..ec65653 100644
--- a/linux-user/mips64/syscall.h
+++ b/linux-user/mips64/syscall.h
@@ -218,4 +218,7 @@ struct target_pt_regs {
+/* Nasty hack: define a fake errno value for use by sigreturn. */
+#define T
[Qemu-devel] Re: [PATCH] ioapic: when switches to level trigger mode, interrupts raised repeatedly.
On Sat, Apr 09, 2011 at 10:38:10AM +0200, Jan Kiszka wrote:
> On 2011-04-04 04:15, Isaku Yamahata wrote:
> > On Mon, Apr 04, 2011 at 08:42:07AM +0900, Isaku Yamahata wrote:
> >> > Thank you for applying. But I found that the patch is wrong and
> >> > I'm preparing the new one. Can you please revert it?
> > Here is the corrected patch. The first wrong patch clears the interrupts
> > bit unconditionally. Which caused losing interrupt.
> >
> > From 5ed177d35ab14f3b070a0eba2c49400279a3a14b Mon Sep 17 00:00:00 2001
> > Message-Id:
> > <5ed177d35ab14f3b070a0eba2c49400279a3a14b.1301883258.git.yamah...@valinux.co.jp>
> > In-Reply-To:
> > References:
> > From: Isaku Yamahata
> > Date: Wed, 16 Mar 2011 14:00:13 +0900
> > Subject: [PATCH 01/30] ioapic: when switches to level trigger mode,
> > interrupts raised repeatedly.
> >
> > - the trigger mode is edge at first by reset.
> > - During initializatoin, the interrupt is raised as edge which is masked.
> > The corresponding bit of irr is set.
>
> ...and that is the actual problem. The spec says: "Interrupt Mask?R/W.
> When this bit is 1, the interrupt signal is masked. Edge-sensitive
> interrupts signaled on a masked interrupt pin are ignored (i.e., not
> delivered or held pending)."
>
> So this should do the trick in a correct way (untested, please
> validate):
Thank you for referring the spec. It works.
Here's the updated patch with your signed-off-by and my tested-by.
>From a6c92855357a24da6a0d8d6e76dcca735a4be885 Mon Sep 17 00:00:00 2001
Message-Id:
In-Reply-To:
References:
From: Isaku Yamahata
Date: Wed, 16 Mar 2011 14:00:13 +0900
Subject: [PATCH] ioapic: when switches to level trigger mode, interrupts raised
repeatedly.
- the trigger mode is edge at first by reset.
- During initializatoin, the interrupt is raised as edge which is masked.
The corresponding bit of irr is set.
the bit must not be set when masked
- Then the mode is switched to level and it's unmasked with the same write.
- the bit of irr is set, so the interrupt is raised repeatedly by
ioapic_service().
- OS considers that the irq line is broken and falls back to polling mode.
>From the specification, the masked edge triggered interrupt must
be ingored as follows.
3.4.2 I/O redirection table registers: Interrupt Mask
Edge-sensitive interrupts signaled on a masked interrupt pin
are ignored (i.e., not delivered or held pending).
> Bringing up interface eth0:
> Determining IP information for eth0...irq 18: nobody cared (try booting with
> the "irqpoll" option)
> Pid: 4126, comm: ip Not tainted 2.6.38-rc7 #1
> Call Trace:
>[] ? __report_bad_irq+0x38/0x87
> [] ? note_interrupt+0x11f/0x188
> [] ? handle_fasteoi_irq+0xa7/0xd1
> [] ? handle_irq+0x83/0x8c
> [] ? do_IRQ+0x48/0xaf
> [] ? ret_from_intr+0x0/0xe
> [] ? __do_softirq+0x4f/0x114
> [] ? call_softirq+0x1c/0x28
> [] ? do_softirq+0x33/0x68
> [] ? irq_exit+0x36/0x38
> [] ? smp_apic_timer_interrupt+0x88/0x96
> [] ? apic_timer_interrupt+0x13/0x20
>[] ? __ioapic_set_affinity+0x68/0x7c
> [] ? _raw_spin_unlock_irqrestore+0x8/0xa
> [] ? __setup_irq+0x224/0x2cb
> [] ? e1000_intr+0x0/0x103
> [] ? request_threaded_irq+0xd1/0x114
> [] ? e1000_request_irq+0x34/0x63
> [] ? e1000_open+0x81/0x11f
> [] ? call_netdevice_notifiers+0x45/0x4a
> [] ? __dev_open+0x97/0xc4
> [] ? __dev_change_flags+0xb9/0x13d
> [] ? dev_change_flags+0x1c/0x51
> [] ? devinet_ioctl+0x26e/0x594
> [] ? inet_ioctl+0x92/0xaa
> [] ? T.1003+0x13/0x32
> [] ? sock_ioctl+0x1f2/0x1ff
> [] ? do_vfs_ioctl+0x498/0x4e7
> [] ? sock_alloc_file+0xb3/0x115
> [] ? fd_install+0x31/0x5d
> [] ? sys_ioctl+0x42/0x65
> [] ? system_call_fastpath+0x16/0x1b
> handlers:
> [] (e1000_intr+0x0/0x103)
> Disabling IRQ #18
Signed-off-by: Jan Kiszka
Tested-by: Isaku Yamahata
---
hw/ioapic.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 569327d..42c5037 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -160,8 +160,13 @@ static void ioapic_set_irq(void *opaque, int vector, int
level)
s->irr &= ~mask;
}
} else {
-/* edge triggered */
-if (level) {
+/*
+ * edge triggered
+ * 3.4.2 I/O redirection table registers: Interrupt Mask
+ * Edge-sensitive interrupts signaled on a masked interrupt pin
+ * are ignored (i.e., not delivered or held pending).
+ */
+if (level && !(entry & IOAPIC_LVT_MASKED)) {
s->irr |= mask;
ioapic_service(s);
}
--
1.7.1.1
--
yamahata
Re: [Qemu-devel] [PATCH] mpc85xx_pci_map_irq: change "unknow" to "unknown".
Merged into the trivial patches tree: git://repo.or.cz/qemu/stefanha.git trivial-patches A pull request will be sent to merge this into qemu.git. For more information, see http://wiki.qemu.org/Contribute/TrivialPatches. Stefan
[Qemu-devel] [PATCH] ioapic: Do not set irr for masked edge IRQs
On 2011-04-09 13:05, Isaku Yamahata wrote:
> On Sat, Apr 09, 2011 at 10:38:10AM +0200, Jan Kiszka wrote:
>> On 2011-04-04 04:15, Isaku Yamahata wrote:
>>> On Mon, Apr 04, 2011 at 08:42:07AM +0900, Isaku Yamahata wrote:
> Thank you for applying. But I found that the patch is wrong and
> I'm preparing the new one. Can you please revert it?
>>> Here is the corrected patch. The first wrong patch clears the interrupts
>>> bit unconditionally. Which caused losing interrupt.
>>>
>>> From 5ed177d35ab14f3b070a0eba2c49400279a3a14b Mon Sep 17 00:00:00 2001
>>> Message-Id:
>>> <5ed177d35ab14f3b070a0eba2c49400279a3a14b.1301883258.git.yamah...@valinux.co.jp>
>>> In-Reply-To:
>>> References:
>>> From: Isaku Yamahata
>>> Date: Wed, 16 Mar 2011 14:00:13 +0900
>>> Subject: [PATCH 01/30] ioapic: when switches to level trigger mode,
>>> interrupts raised repeatedly.
>>>
>>> - the trigger mode is edge at first by reset.
>>> - During initializatoin, the interrupt is raised as edge which is masked.
>>> The corresponding bit of irr is set.
>>
>> ...and that is the actual problem. The spec says: "Interrupt Mask?R/W.
>> When this bit is 1, the interrupt signal is masked. Edge-sensitive
>> interrupts signaled on a masked interrupt pin are ignored (i.e., not
>> delivered or held pending)."
>>
>> So this should do the trick in a correct way (untested, please
>> validate):
>
> Thank you for referring the spec. It works.
> Here's the updated patch with your signed-off-by and my tested-by.
Thanks for testing. I would prefer the following more compact wordings.
Jan
-8<--
From: Jan Kiszka
So far we set IRR for edge IRQs even if the pin is masked. If the guest
later on unmasks and switches the pin to level-triggered mode, irr will
remain set, causing an IRQ storm. The point is that setting IRR is not
correct in this case according to the spec, and avoiding this resolves
the issue.
Reported-and-tested-by: Isaku Yamahata
Signed-off-by: Jan Kiszka
---
hw/ioapic.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 569327d..6c26e82 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -160,8 +160,9 @@ static void ioapic_set_irq(void *opaque, int vector, int
level)
s->irr &= ~mask;
}
} else {
-/* edge triggered */
-if (level) {
+/* According to the 82093AA manual, we must ignore edge requests
+ * if the input pin is masked. */
+if (level && !(entry & IOAPIC_LVT_MASKED)) {
s->irr |= mask;
ioapic_service(s);
}
--
1.7.1
[Qemu-devel] Re: [PATCH v2] configure: avoid basename usage message
On Fri, Apr 08, 2011 at 02:15:50PM -0500, Scott Wood wrote: > basename prints a missing-argument error when sdlconfig is empty > and we're cross-compiling. > > Signed-off-by: Scott Wood > --- > v2: quote the input to basename rather than introduce an extra test, > as suggested by Stefan. > > configure |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) I have merged into the trivial patches tree since $() is POSIX and we already use it in ./configure: git://repo.or.cz/qemu/stefanha.git trivial-patches A pull request will be sent to merge this into qemu.git. For more information, see http://wiki.qemu.org/Contribute/TrivialPatches. Stefan
Re: [Qemu-devel] [PATCH] event: trivial coding style fixes.
On Sat, Apr 09, 2011 at 12:11:36PM +1000, Brad Hards wrote: > > Signed-off-by: Brad Hards > --- > input.c | 14 +++--- > 1 files changed, 7 insertions(+), 7 deletions(-) The rest of the file follows the coding style, so I guess this change is reasonable. Merged into the trivial patches tree: git://repo.or.cz/qemu/stefanha.git trivial-patches A pull request will be sent to merge this into qemu.git. For more information, see http://wiki.qemu.org/Contribute/TrivialPatches. Stefan
[Qemu-devel] [PULL] Trivial patches for 8-9 April 2011
The following changes since commit 6957785773e8a3cc8bd51f0e3172eaccbbaa5f3a: ppce500_mpc8544ds: Fix compile with --enable-debug and --disable-kvm (2011-04-08 12:20:08 +0200) are available in the git repository at: git://repo.or.cz/qemu/stefanha.git trivial-patches Adam Lackorzynski (1): multiboot: Quote filename in error message Brad Hards (1): event: trivial coding style fixes Scott Wood (2): mpc85xx_pci_map_irq: change "unknow" to "unknown" configure: avoid basename usage message configure|2 +- hw/multiboot.c |2 +- hw/ppce500_pci.c |2 +- input.c | 14 +++--- 4 files changed, 10 insertions(+), 10 deletions(-)
[Qemu-devel] Re: [PATCH] ioapic: Do not set irr for masked edge IRQs
On 2011-04-09 13:18, Jan Kiszka wrote:
> On 2011-04-09 13:05, Isaku Yamahata wrote:
>> On Sat, Apr 09, 2011 at 10:38:10AM +0200, Jan Kiszka wrote:
>>> On 2011-04-04 04:15, Isaku Yamahata wrote:
On Mon, Apr 04, 2011 at 08:42:07AM +0900, Isaku Yamahata wrote:
>> Thank you for applying. But I found that the patch is wrong and
>> I'm preparing the new one. Can you please revert it?
Here is the corrected patch. The first wrong patch clears the interrupts
bit unconditionally. Which caused losing interrupt.
From 5ed177d35ab14f3b070a0eba2c49400279a3a14b Mon Sep 17 00:00:00 2001
Message-Id:
<5ed177d35ab14f3b070a0eba2c49400279a3a14b.1301883258.git.yamah...@valinux.co.jp>
In-Reply-To:
References:
From: Isaku Yamahata
Date: Wed, 16 Mar 2011 14:00:13 +0900
Subject: [PATCH 01/30] ioapic: when switches to level trigger mode,
interrupts raised repeatedly.
- the trigger mode is edge at first by reset.
- During initializatoin, the interrupt is raised as edge which is masked.
The corresponding bit of irr is set.
>>>
>>> ...and that is the actual problem. The spec says: "Interrupt Mask?R/W.
>>> When this bit is 1, the interrupt signal is masked. Edge-sensitive
>>> interrupts signaled on a masked interrupt pin are ignored (i.e., not
>>> delivered or held pending)."
>>>
>>> So this should do the trick in a correct way (untested, please
>>> validate):
>>
>> Thank you for referring the spec. It works.
>> Here's the updated patch with your signed-off-by and my tested-by.
>
> Thanks for testing. I would prefer the following more compact wordings.
>
> Jan
>
> -8<--
>
> From: Jan Kiszka
>
> So far we set IRR for edge IRQs even if the pin is masked. If the guest
> later on unmasks and switches the pin to level-triggered mode, irr will
> remain set, causing an IRQ storm. The point is that setting IRR is not
> correct in this case according to the spec, and avoiding this resolves
> the issue.
>
> Reported-and-tested-by: Isaku Yamahata
> Signed-off-by: Jan Kiszka
> ---
> hw/ioapic.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ioapic.c b/hw/ioapic.c
> index 569327d..6c26e82 100644
> --- a/hw/ioapic.c
> +++ b/hw/ioapic.c
> @@ -160,8 +160,9 @@ static void ioapic_set_irq(void *opaque, int vector, int
> level)
> s->irr &= ~mask;
> }
> } else {
> -/* edge triggered */
> -if (level) {
> +/* According to the 82093AA manual, we must ignore edge requests
> + * if the input pin is masked. */
> +if (level && !(entry & IOAPIC_LVT_MASKED)) {
> s->irr |= mask;
> ioapic_service(s);
> }
On first glance, it looks like KVM's in-kernel IOAPIC model is affected
by the same issue. As you have the test case at hand, could you run it
against qemu-kvm which stresses the kernel version?
TIA,
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH] ioapic: Do not set irr for masked edge IRQs
On 2011-04-09 13:26, Jan Kiszka wrote:
> On 2011-04-09 13:18, Jan Kiszka wrote:
>> On 2011-04-09 13:05, Isaku Yamahata wrote:
>>> On Sat, Apr 09, 2011 at 10:38:10AM +0200, Jan Kiszka wrote:
On 2011-04-04 04:15, Isaku Yamahata wrote:
> On Mon, Apr 04, 2011 at 08:42:07AM +0900, Isaku Yamahata wrote:
>>> Thank you for applying. But I found that the patch is wrong and
>>> I'm preparing the new one. Can you please revert it?
> Here is the corrected patch. The first wrong patch clears the interrupts
> bit unconditionally. Which caused losing interrupt.
>
> From 5ed177d35ab14f3b070a0eba2c49400279a3a14b Mon Sep 17 00:00:00 2001
> Message-Id:
> <5ed177d35ab14f3b070a0eba2c49400279a3a14b.1301883258.git.yamah...@valinux.co.jp>
> In-Reply-To:
> References:
> From: Isaku Yamahata
> Date: Wed, 16 Mar 2011 14:00:13 +0900
> Subject: [PATCH 01/30] ioapic: when switches to level trigger mode,
> interrupts raised repeatedly.
>
> - the trigger mode is edge at first by reset.
> - During initializatoin, the interrupt is raised as edge which is masked.
> The corresponding bit of irr is set.
...and that is the actual problem. The spec says: "Interrupt Mask?R/W.
When this bit is 1, the interrupt signal is masked. Edge-sensitive
interrupts signaled on a masked interrupt pin are ignored (i.e., not
delivered or held pending)."
So this should do the trick in a correct way (untested, please
validate):
>>>
>>> Thank you for referring the spec. It works.
>>> Here's the updated patch with your signed-off-by and my tested-by.
>>
>> Thanks for testing. I would prefer the following more compact wordings.
>>
>> Jan
>>
>> -8<--
>>
>> From: Jan Kiszka
>>
>> So far we set IRR for edge IRQs even if the pin is masked. If the guest
>> later on unmasks and switches the pin to level-triggered mode, irr will
>> remain set, causing an IRQ storm. The point is that setting IRR is not
>> correct in this case according to the spec, and avoiding this resolves
>> the issue.
>>
>> Reported-and-tested-by: Isaku Yamahata
>> Signed-off-by: Jan Kiszka
>> ---
>> hw/ioapic.c |5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/ioapic.c b/hw/ioapic.c
>> index 569327d..6c26e82 100644
>> --- a/hw/ioapic.c
>> +++ b/hw/ioapic.c
>> @@ -160,8 +160,9 @@ static void ioapic_set_irq(void *opaque, int vector, int
>> level)
>> s->irr &= ~mask;
>> }
>> } else {
>> -/* edge triggered */
>> -if (level) {
>> +/* According to the 82093AA manual, we must ignore edge requests
>> + * if the input pin is masked. */
>> +if (level && !(entry & IOAPIC_LVT_MASKED)) {
>> s->irr |= mask;
>> ioapic_service(s);
>> }
>
> On first glance, it looks like KVM's in-kernel IOAPIC model is affected
> by the same issue. As you have the test case at hand, could you run it
> against qemu-kvm which stresses the kernel version?
On second glance, it should be fine as it clears irr unconditionally on
the falling edge. Both approaches look valid to me as irr is just an
internal state.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH] ioapic: Do not set irr for masked edge IRQs
On Sat, Apr 09, 2011 at 01:26:07PM +0200, Jan Kiszka wrote: > On first glance, it looks like KVM's in-kernel IOAPIC model is affected > by the same issue. Agreed. > As you have the test case at hand, could you run it > against qemu-kvm which stresses the kernel version? Unfortunately I don't have kvm test case yet because I found this issue when trying to change IOAPIC irq routing. -- yamahata
[Qemu-devel] [Bug 721659] Re: qemu-kvm-0.13.0 doesn't pass USB devices to the VM
Hi, Thanks for reporting this problem. Can you tell me a bit more about your configuration? For example: What are the guest and host operating systems? Is it always "need -1"? Do you ever see "need 1"? What is the device you're trying to open? Can you show the USB descriptors (e.g. from lsusb)? Do you have rights to open the device (e.g. are you running qemu with elevated privileges)? Does it help / change things if you do or don't? I'm not sure that the error messages are very accurate in this particular case. I think the problem with those messages comes from use of perror() in the QEMU code and that the underlying operations aren't returning / setting errno in the right way (or perhaps at all). However the fact that we're even getting to the error path indicates a problem. If I had to guess, the device is already bound to a driver on the host and you don't have permissions to unbind it. However I'm pretty fuzzy on this one, and I'm really hoping the additional information might help someone else fix it. Brad -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/721659 Title: qemu-kvm-0.13.0 doesn't pass USB devices to the VM Status in QEMU: New Bug description: I have the bug, similar to this one: https://bugzilla.redhat.com/show_bug.cgi?id=583108 but under gentoo When I add parameters -usb -usbdevice host:4348:5584, I see the following lines in console: husb: config #1 need -1 USBDEVFS_DISCONNECT: No route to host husb: open device 2.11 (...many repetitions of three above lines...) All parameters (2.11) are verified with lsusb at host computer - parameters are correct Error description is very confusing - I don't know what to check, what "config #1" mean, which route should be checked and how to check it.
[Qemu-devel] Re: Slow PXE boot in qemu.git (fast in qemu-kvm.git)
On Sat, Apr 9, 2011 at 1:50 AM, Anthony Liguori wrote: > On 04/08/2011 06:25 PM, Luiz Capitulino wrote: >> >> Hi there, >> >> Summary: >> >> - PXE boot in qemu.git (HEAD f124a41) is quite slow, more than 5 minutes. >> Got >> the problem with e1000, virtio and rtl8139. However, pcnet *works* >> (it's >> as fast as qemu-kvm.git) >> >> - PXE boot in qemu-kvm.git (HEAD df85c051) is fast, less than a minute. >> Tried >> with e1000, virtio and rtl8139 (I don't remember if I tried with pcnet) >> >> I tried with qemu.git v0.13.0 in order to check if this was a regression, >> but >> I got the same problem... >> >> Then I inspected qemu-kvm.git under the assumption that it could have a >> fix >> that wasn't commited to qemu.git. Found this: >> >> - commit 0836b77f0f65d56d08bdeffbac25cd6d78267dc9 which is merge, works >> >> - commit cc015e9a5dde2f03f123357fa060acbdfcd570a4 does not work (it's >> slow) >> >> I tried a bisect, but it brakes due to gcc4 vs. gcc3 changes. Then I >> inspected >> commits manually, and found out that commit 64d7e9a4 doesn't work, which >> makes >> me think that the fix could be in the conflict resolution of 0836b77f, >> which >> makes me remember that I'm late for diner, so my conclusions at this point >> are >> not reliable :) > > Can you run kvm_stat to see what the exit rates are? > > Maybe we're missing a coalesced io in qemu.git? It's also possible that > gpxe is hitting the apic or pit quite a lot. In gPXE's main loop it will do real <-> protected mode switches and poll hardware. It doesn't handle interrupts itself but sets up the 8254 timer chip. I once found that polling the keyboard only every couple of gPXE main loop iterations significantly speeds up network throughput under KVM. I never got around to auditing the entire main loop and implementing a clean patch. Anyway, kvm_stat is a good idea. It may be tickling qemu in a way that qemu-kvm is immune to. Stefan
Re: [Qemu-devel] [PULL] Trivial patches for 8-9 April 2011
On Sat, Apr 09, 2011 at 12:25:42PM +0100, Stefan Hajnoczi wrote: > The following changes since commit 6957785773e8a3cc8bd51f0e3172eaccbbaa5f3a: > > ppce500_mpc8544ds: Fix compile with --enable-debug and --disable-kvm > (2011-04-08 12:20:08 +0200) > > are available in the git repository at: > git://repo.or.cz/qemu/stefanha.git trivial-patches > > Adam Lackorzynski (1): > multiboot: Quote filename in error message > > Brad Hards (1): > event: trivial coding style fixes > > Scott Wood (2): > mpc85xx_pci_map_irq: change "unknow" to "unknown" > configure: avoid basename usage message > > configure|2 +- > hw/multiboot.c |2 +- > hw/ppce500_pci.c |2 +- > input.c | 14 +++--- > 4 files changed, 10 insertions(+), 10 deletions(-) > > Thanks, pulled. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH 5/5] atapi: Implement 'media' subcommand of GET_EVENT_STATUS_NOTIFICATION command
On (Fri) 08 Apr 2011 [18:17:38], Kevin Wolf wrote:
> Am 08.04.2011 09:15, schrieb Amit Shah:
> > Implement the 'media' sub-command of the GET_EVENT_STATUS_NOTIFICATION
> > command. This helps us report tray open, tray closed, no media, media
> > present states to the guest.
> >
> > Newer Linux kernels (2.6.38+) rely on this command to revalidate discs
> > after media change.
> >
> > This patch also sends out tray open/closed status to the guest driver
> > when requested e.g. via the CDROM_DRIVE_STATUS ioctl (thanks Markus).
> > Without such notification, the guest and qemu's tray open/close status
> > was frequently out of sync, causing installers like Anaconda detecting
> > no disc instead of tray open, confusing them terribly.
> >
> > Signed-off-by: Amit Shah
> > ---
> > hw/ide/core.c | 93
> > +++-
> > hw/ide/internal.h |6 +++
> > 2 files changed, 97 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index cdc2c56..627b2cf 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -1084,6 +1084,57 @@ static int ide_dvd_read_structure(IDEState *s, int
> > format,
> > }
> > }
> >
> > +static unsigned int event_status_media(IDEState *s,
> > + uint8_t *buf,
> > + unsigned int max_len,
> > + unsigned int event_class,
> > + unsigned int supported_events)
> > +{
> > +enum media_event_code {
> > +no_change = 0, /* Status unchanged */
> > +eject_requested, /* received a request from user to eject */
> > +new_media, /* new media inserted and ready for access */
> > +media_removal, /* only for media changers */
> > +media_changed, /* only for media changers */
> > +bg_format_completed, /* MRW or DVD+RW b/g format completed */
> > +bg_format_restarted, /* MRW or DVD+RW b/g format restarted */
> > +};
> > +enum media_status {
> > +tray_open = 1,
> > +media_present = 2,
> > +};
> > +uint8_t event_code, media_status;
> > +
> > +if (max_len < 6) {
> > +/* We're going to use 6 bytes; don't report anything if we have
> > less */
> > +return 0;
> > +}
>
> Why? Shouldn't we report the first few bytes?
This shouldn't be necessary at all now, isn't it?
> > +
> > +/* Event notification header */
> > +cpu_to_ube16(buf, max_len);
> > +buf[2] = event_class;
> > +buf[3] = supported_events;
>
> This should be done in handle_get_event_status_notification as it's not
> specific for media events.
Yes, I moved it here just before the submission. With the used_len
stuff not being needed anymore, this can be put back there and code
won't look too ugly.
> > +media_status = 0;
> > +if (s->bs->tray_open) {
> > +media_status = tray_open;
> > +} else if (bdrv_is_inserted(s->bs)) {
> > +media_status = media_present;
> > +}
> > +
> > +/* Event notification descriptor */
> > +event_code = no_change;
> > +if (media_status != tray_open && s->events.new_media) {
> > +event_code = new_media;
> > +s->events.new_media = false;
> > +}
> > +
> > +buf[4] = event_code;
> > +buf[5] = media_status;
> > +
> > +return 6; /* We wrote to just 2 extra bytes from the header */
>
> After media_state, there are two more fields for start/end slot (even
> though they are reserved because we don't have a multiple slot device)
Yes, they're reserved, so we shouldn't change them. Any change might
trigger bad response from guests.
> So I think we should return 8 and possible zero bytes 6 and 7.
>
> > +}
> > +
> > static unsigned int event_status_nea(uint8_t *buf, unsigned int max_len)
> > {
> > unsigned int used_len;
> > @@ -1125,7 +1176,28 @@ static void
> > handle_get_event_status_notification(IDEState *s,
> > allocation_length_lsb = 8,
> > control = 9,
> > };
> > +enum notification_class_request_type {
> > +reserved1 = 1 << 0,
> > +operational_change = 1 << 1,
> > +power_management = 1 << 2,
> > +external_request = 1 << 3,
> > +media = 1 << 4,
> > +multi_host = 1 << 5,
> > +device_busy = 1 << 6,
> > +reserved2 = 1 << 7,
> > +};
> > +enum event_notification_class_field {
> > +enc_no_events = 0,
> > +enc_operational_change,
> > +enc_power_management,
> > +enc_external_request,
> > +enc_media,
> > +enc_multiple_hosts,
> > +enc_device_busy,
> > +enc_reserved,
> > +};
> > unsigned int max_len, used_len;
> > +unsigned int supported_events;
> >
> > max_len = ube16_to_cpu(packet + allocation_length_msb);
> >
> > @@ -1139,8 +1211,24 @@ static void
> > handle_get_event_status_not
[Qemu-devel] [PATCH] ppc: remove a write-only variable
Remove a write-only variable, spotted by GCC 4.6.0:
/src/qemu/hw/ppc.c: In function 'power7_set_irq':
/src/qemu/hw/ppc.c:255:9: error: variable 'cur_level' set but not used
[-Werror=unused-but-set-variable]
Signed-off-by: Blue Swirl
---
hw/ppc.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hw/ppc.c b/hw/ppc.c
index dabb816..1873328 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -252,11 +252,9 @@ void ppc970_irq_init (CPUState *env)
static void power7_set_irq (void *opaque, int pin, int level)
{
CPUState *env = opaque;
-int cur_level;
LOG_IRQ("%s: env %p pin %d level %d\n", __func__,
env, pin, level);
-cur_level = (env->irq_input_state >> pin) & 1;
switch (pin) {
case POWER7_INPUT_INT:
--
1.7.2.5
[Qemu-devel] Re: [PATCH] ppc: remove a write-only variable
Am 09.04.2011 um 16:56 schrieb Blue Swirl :
> Remove a write-only variable, spotted by GCC 4.6.0:
> /src/qemu/hw/ppc.c: In function 'power7_set_irq':
> /src/qemu/hw/ppc.c:255:9: error: variable 'cur_level' set but not used
> [-Werror=unused-but-set-variable]
>
> Signed-off-by: Blue Swirl
> ---
> hw/ppc.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/hw/ppc.c b/hw/ppc.c
> index dabb816..1873328 100644
> --- a/hw/ppc.c
> +++ b/hw/ppc.c
> @@ -252,11 +252,9 @@ void ppc970_irq_init (CPUState *env)
> static void power7_set_irq (void *opaque, int pin, int level)
> {
> CPUState *env = opaque;
> -int cur_level;
>
> LOG_IRQ("%s: env %p pin %d level %d\n", __func__,
> env, pin, level);
> -cur_level = (env->irq_input_state >> pin) & 1;
David, Ben?
Alex
>
Re: [Qemu-devel] [PATCH] hw/pflash_cfi02: Fix lazy reset of ROMD mode
On Sun, Apr 03, 2011 at 01:16:26PM -0700, Jordan Justen wrote:
> When checking pfl->rom_mode for when to lazily reenter ROMD mode,
> the value was check was the opposite of what it should have been.
> This prevent the part from returning to ROMD mode after a write
> was made to the CFI rom region.
>
> Signed-off-by: Jordan Justen
> ---
> hw/pflash_cfi02.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, applied.
> diff --git a/hw/pflash_cfi02.c b/hw/pflash_cfi02.c
> index 30c8aa4..370c5ee 100644
> --- a/hw/pflash_cfi02.c
> +++ b/hw/pflash_cfi02.c
> @@ -112,7 +112,7 @@ static uint32_t pflash_read (pflash_t *pfl,
> target_phys_addr_t offset,
>
> DPRINTF("%s: offset " TARGET_FMT_plx "\n", __func__, offset);
> ret = -1;
> -if (pfl->rom_mode) {
> +if (!pfl->rom_mode) {
> /* Lazy reset of to ROMD mode */
> if (pfl->wcycle == 0)
> pflash_register_memory(pfl, 1);
> --
> 1.7.1
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 0/4] acpi: factor out fixed hardware logic
On Fri, Mar 25, 2011 at 07:54:37PM +0900, Isaku Yamahata wrote: > So far acpi fixed hardware logic (PM TMR, PM1a_EVT, PM1_CNT and GPE0) > are embedded in each device.(acpi_piix.c and vt82c686). > This patch series factors out the logic and consolidate them. > This was the part of q35 chipset patch series which also implements > acpi fixed hardware. > But I made the acpi part independent patch series to make the merge easy. > > Isaku Yamahata (4): > acpi, acpi_piix, vt82c686: factor out PM_TMR logic > acpi, acpi_piix, vt82c686: factor out PM1a EVT logic > acpi, acpi_piix, vt82c686: factor out PM1_CNT logic > acpi, acpi_piix: factor out GPE logic > > hw/acpi.c | 197 + > hw/acpi.h | 68 + > hw/acpi_piix4.c | 220 +- > hw/vt82c686.c | 110 +++ > 4 files changed, 346 insertions(+), 249 deletions(-) > Thanks, applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Question about total_sectors in block/vpc.c
Hell all, I have take a look of block/vpc.c and meet a question in vpc_create(). At the line 550, the code is: total_sectors = options->value.n / 512; I am wondering whether the size between total_sectors * 512 and options->value.n would be discard. Thanks Mitnick
Re: [Qemu-devel] Question about total_sectors in block/vpc.c
On Sat, Apr 9, 2011 at 5:51 PM, Lyu Mitnick wrote: > Hell all, > I have take a look of block/vpc.c and meet a question in vpc_create(). At > the line > 550, the code is: > total_sectors = options->value.n / 512; > I am wondering whether the size between total_sectors * 512 > and options->value.n > would be discard. Yes, it rounds down. This reflects the assumption that a block device cannot be addressed below 512 byte sectors. Because of this block devices size must be a multiple of 512 bytes. I think a reasonable protection would be to have block.c:bdrv_create() fail if size is not a multiple of BDRV_SECTOR_SIZE. This way other image formats are protected too. Stefan
[Qemu-devel] [PATCH] configure: disable opengl per default
There is a bug in nvidia's binary GPU driver, which causes a segmentation fault if linked to libGL. Signed-off-by: Michael Walle --- configure |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure b/configure index 2bb3faa..be40a31 100755 --- a/configure +++ b/configure @@ -177,6 +177,7 @@ spice="" rbd="" smartcard="" smartcard_nss="" +opengl="no" # parse CC options first for opt do -- 1.7.2.3
Re: [Qemu-devel] [PATCH] smbus_eeprom: consolidate smbus eeprom creation oc pc_piix, mips_mapta, mips_fulong
On Tue, Apr 05, 2011 at 11:07:06AM +0900, Isaku Yamahata wrote:
> consolidate smbus initialization for pc_piix, mips_malta and mips_fulong.
>
> Cc: Aurelien Jarno
> Cc: Huacai Chen
> Signed-off-by: Isaku Yamahata
> Reviewed-by: Aurelien Jarno
> ---
> hw/mips_fulong2e.c |9 +
> hw/mips_malta.c| 12 ++--
> hw/pc_piix.c | 10 ++
> hw/smbus.h |3 +++
> hw/smbus_eeprom.c | 22 --
> 5 files changed, 28 insertions(+), 28 deletions(-)
Thanks, applied.
> diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
> index 0e90d68..420fada 100644
> --- a/hw/mips_fulong2e.c
> +++ b/hw/mips_fulong2e.c
> @@ -263,11 +263,9 @@ static void mips_fulong2e_init(ram_addr_t ram_size,
> const char *boot_device,
> qemu_irq *cpu_exit_irq;
> int via_devfn;
> PCIBus *pci_bus;
> -uint8_t *eeprom_buf;
> i2c_bus *smbus;
> int i;
> DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> -DeviceState *eeprom;
> CPUState *env;
>
> /* init CPUs */
> @@ -353,13 +351,8 @@ static void mips_fulong2e_init(ram_addr_t ram_size,
> const char *boot_device,
>
> smbus = vt82c686b_pm_init(pci_bus, PCI_DEVFN(FULONG2E_VIA_SLOT, 4),
>0xeee1, NULL);
> -eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this persistent */
> -memcpy(eeprom_buf, eeprom_spd, sizeof(eeprom_spd));
> /* TODO: Populate SPD eeprom data. */
> -eeprom = qdev_create((BusState *)smbus, "smbus-eeprom");
> -qdev_prop_set_uint8(eeprom, "address", 0x50);
> -qdev_prop_set_ptr(eeprom, "data", eeprom_buf);
> -qdev_init_nofail(eeprom);
> +smbus_eeprom_init(smbus, 1, eeprom_spd, sizeof(eeprom_spd));
>
> /* init other devices */
> pit = pit_init(0x40, 0);
> diff --git a/hw/mips_malta.c b/hw/mips_malta.c
> index bf0d76d..ed2a483 100644
> --- a/hw/mips_malta.c
> +++ b/hw/mips_malta.c
> @@ -770,7 +770,6 @@ void mips_malta_init (ram_addr_t ram_size,
> qemu_irq *i8259;
> qemu_irq *cpu_exit_irq;
> int piix4_devfn;
> -uint8_t *eeprom_buf;
> i2c_bus *smbus;
> int i;
> DriveInfo *dinfo;
> @@ -913,15 +912,8 @@ void mips_malta_init (ram_addr_t ram_size,
> usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
> smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100, isa_get_irq(9),
>NULL, NULL, 0);
> -eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this persistent */
> -for (i = 0; i < 8; i++) {
> -/* TODO: Populate SPD eeprom data. */
> -DeviceState *eeprom;
> -eeprom = qdev_create((BusState *)smbus, "smbus-eeprom");
> -qdev_prop_set_uint8(eeprom, "address", 0x50 + i);
> -qdev_prop_set_ptr(eeprom, "data", eeprom_buf + (i * 256));
> -qdev_init_nofail(eeprom);
> -}
> +/* TODO: Populate SPD eeprom data. */
> +smbus_eeprom_init(smbus, 8, NULL, 0);
> pit = pit_init(0x40, 0);
> cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
> DMA_init(0, cpu_exit_irq);
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index 4d54ca1..a85214b 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -37,6 +37,7 @@
> #include "sysbus.h"
> #include "arch_init.h"
> #include "blockdev.h"
> +#include "smbus.h"
>
> #define MAX_IDE_BUS 2
>
> @@ -154,7 +155,6 @@ static void pc_init1(ram_addr_t ram_size,
> }
>
> if (pci_enabled && acpi_enabled) {
> -uint8_t *eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this
> persistent */
> i2c_bus *smbus;
>
> cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
> @@ -163,13 +163,7 @@ static void pc_init1(ram_addr_t ram_size,
> smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
>isa_get_irq(9), *cmos_s3, *smi_irq,
>kvm_enabled());
> -for (i = 0; i < 8; i++) {
> -DeviceState *eeprom;
> -eeprom = qdev_create((BusState *)smbus, "smbus-eeprom");
> -qdev_prop_set_uint8(eeprom, "address", 0x50 + i);
> -qdev_prop_set_ptr(eeprom, "data", eeprom_buf + (i * 256));
> -qdev_init_nofail(eeprom);
> -}
> +smbus_eeprom_init(smbus, 8, NULL, 0);
> }
>
> if (i440fx_state) {
> diff --git a/hw/smbus.h b/hw/smbus.h
> index 571c52d..a398715 100644
> --- a/hw/smbus.h
> +++ b/hw/smbus.h
> @@ -66,3 +66,6 @@ void smbus_write_word(i2c_bus *bus, uint8_t addr, uint8_t
> command, uint16_t data
> int smbus_read_block(i2c_bus *bus, uint8_t addr, uint8_t command, uint8_t
> *data);
> void smbus_write_block(i2c_bus *bus, uint8_t addr, uint8_t command, uint8_t
> *data,
> int len);
> +
> +void smbus_eeprom_init(i2c_bus *smbus, int nb_eeprom,
> + const uint8_t *eeprom_spd, int size);
> diff --git a/hw/smbus_eeprom.c b/hw/smbus_eeprom.c
> index 52463e0..3634754 100644
> --- a/hw/smbus_eeprom.c
> +++ b/hw/
Re: [Qemu-devel] [PATCH 4/4] vnc: Limit r/w access to size of allocated memory
On Mon, Mar 21, 2011 at 09:34:38AM +0100, Corentin Chary wrote:
> From: Stefan Weil
>
> This fixes memory reads and writes which exceeded the upper limit
> of allocated memory vd->guest.ds->data and vd->server->data.
>
> Cc: Anthony Liguori
> Signed-off-by: Stefan Weil
> Signed-off-by: Corentin Chary
> ---
> ui/vnc.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/ui/vnc.c b/ui/vnc.c
> index 90b6384..3138053 100644
> --- a/ui/vnc.c
> +++ b/ui/vnc.c
> @@ -2414,6 +2414,9 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
> * Update server dirty map.
> */
> cmp_bytes = 16 * ds_get_bytes_per_pixel(vd->ds);
> +if (cmp_bytes > vd->ds->surface->linesize) {
> +cmp_bytes = vd->ds->surface->linesize;
> +}
What about using ds_get_linesize(vd->ds) instead?
> guest_row = vd->guest.ds->data;
> server_row = vd->server->data;
> for (y = 0; y < vd->guest.ds->height; y++) {
> --
> 1.7.3.4
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 1/4] vnc: tight: Fix crash after 2GB of output
On Mon, Mar 21, 2011 at 09:34:35AM +0100, Corentin Chary wrote:
> From: Michael Tokarev
>
> fix 2Gb integer overflow in in VNC tight and zlib encodings
>
> As found by Roland Dreier (excellent
> catch!), when amount of VNC compressed data produced by zlib
> and sent to client exceeds 2Gb, integer overflow occurs because
> currently, we calculate amount of data produced at each step by
> comparing saved total_out with new total_out, and total_out is
> something which grows without bounds. Compare it with previous
> avail_out instead of total_out, and leave total_out alone.
>
> The same code is used in vnc-enc-tight.c and vnc-enc-zlib.c,
> so fix both cases.
>
> There, there's no actual need to save previous_out value, since
> capacity-offset (which is how that value is calculated) stays
> the same so it can be recalculated again after call to deflate(),
> but whole thing becomes less readable this way.
>
> Reported-by: Roland Dreier
> Signed-off-by: Michael Tokarev
> Signed-off-by: Corentin Chary
> ---
> ui/vnc-enc-tight.c |5 +++--
> ui/vnc-enc-zlib.c |4 ++--
> 2 files changed, 5 insertions(+), 4 deletions(-)
Thanks, applied.
> diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
> index 2522936..87fdf35 100644
> --- a/ui/vnc-enc-tight.c
> +++ b/ui/vnc-enc-tight.c
> @@ -868,8 +868,8 @@ static int tight_compress_data(VncState *vs, int
> stream_id, size_t bytes,
> zstream->avail_in = vs->tight.tight.offset;
> zstream->next_out = vs->tight.zlib.buffer + vs->tight.zlib.offset;
> zstream->avail_out = vs->tight.zlib.capacity - vs->tight.zlib.offset;
> +previous_out = zstream->avail_out;
> zstream->data_type = Z_BINARY;
> -previous_out = zstream->total_out;
>
> /* start encoding */
> if (deflate(zstream, Z_SYNC_FLUSH) != Z_OK) {
> @@ -878,7 +878,8 @@ static int tight_compress_data(VncState *vs, int
> stream_id, size_t bytes,
> }
>
> vs->tight.zlib.offset = vs->tight.zlib.capacity - zstream->avail_out;
> -bytes = zstream->total_out - previous_out;
> +/* ...how much data has actually been produced by deflate() */
> +bytes = previous_out - zstream->avail_out;
>
> tight_send_compact_size(vs, bytes);
> vnc_write(vs, vs->tight.zlib.buffer, bytes);
> diff --git a/ui/vnc-enc-zlib.c b/ui/vnc-enc-zlib.c
> index 3c6e6ab..e32e4cd 100644
> --- a/ui/vnc-enc-zlib.c
> +++ b/ui/vnc-enc-zlib.c
> @@ -103,8 +103,8 @@ static int vnc_zlib_stop(VncState *vs)
> zstream->avail_in = vs->zlib.zlib.offset;
> zstream->next_out = vs->output.buffer + vs->output.offset;
> zstream->avail_out = vs->output.capacity - vs->output.offset;
> +previous_out = zstream->avail_out;
> zstream->data_type = Z_BINARY;
> -previous_out = zstream->total_out;
>
> // start encoding
> if (deflate(zstream, Z_SYNC_FLUSH) != Z_OK) {
> @@ -113,7 +113,7 @@ static int vnc_zlib_stop(VncState *vs)
> }
>
> vs->output.offset = vs->output.capacity - zstream->avail_out;
> -return zstream->total_out - previous_out;
> +return previous_out - zstream->avail_out;
> }
>
> int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int
> h)
> --
> 1.7.3.4
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 1/3] cpu-common: Modify cpu_physical_memory_read and cpu_physical_memory_write
On Sat, Mar 26, 2011 at 09:06:55PM +0100, Stefan Weil wrote:
> A lot of calls don't operate on bytes but on words or on structured data.
> So instead of a pointer to uint8_t, a void pointer is the better choice.
>
> This allows removing many type casts.
>
> (Some very early implementations of memcpy used char pointers
> which were replaced by void pointers for the same reason).
>
> Cc: Blue Swirl
> Signed-off-by: Stefan Weil
> ---
> cpu-common.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpu-common.h b/cpu-common.h
> index ef4e8da..f44a2b0 100644
> --- a/cpu-common.h
> +++ b/cpu-common.h
> @@ -68,12 +68,12 @@ void cpu_unregister_io_memory(int table_address);
> void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> int len, int is_write);
> static inline void cpu_physical_memory_read(target_phys_addr_t addr,
> -uint8_t *buf, int len)
> +void *buf, int len)
> {
> cpu_physical_memory_rw(addr, buf, len, 0);
> }
> static inline void cpu_physical_memory_write(target_phys_addr_t addr,
> - const uint8_t *buf, int len)
> + const void *buf, int len)
> {
> cpu_physical_memory_rw(addr, (uint8_t *)buf, len, 1);
We might want to also do the change here, that is replacing (uint8_t *)
to (void *). Also instead of doing half the job, it would be nice to do
the same changes on cpu_physical_memory_rw().
> }
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 2/3] exec: Remove a type cast which is no longer needed
On Sat, Mar 26, 2011 at 09:06:56PM +0100, Stefan Weil wrote:
> All other type casts in calls of cpu_physical_memory_write are
> used by hardware emulations and will be fixed by separate patches.
>
> Cc: Blue Swirl
> Signed-off-by: Stefan Weil
> ---
> exec.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 964ce31..d7afe30 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -4249,7 +4249,7 @@ void stw_phys(target_phys_addr_t addr, uint32_t val)
> void stq_phys(target_phys_addr_t addr, uint64_t val)
> {
> val = tswap64(val);
> -cpu_physical_memory_write(addr, (const uint8_t *)&val, 8);
> +cpu_physical_memory_write(addr, &val, 8);
> }
>
> /* virtual memory access for debug (includes writing to ROM) */
> --
> 1.7.2.5
>
Reviewed-by: Aurelien Jarno
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 3/3] monitor: Remove some type casts which are no longer needed
On Sat, Mar 26, 2011 at 09:11:05PM +0100, Stefan Weil wrote:
> All other type casts in calls of cpu_physical_memory_read are
> used by hardware emulations and will be fixed by separate patches.
>
> v2: Fixed subject line
>
> Cc: Blue Swirl
> Signed-off-by: Stefan Weil
> ---
> monitor.c | 48 ++--
> 1 files changed, 18 insertions(+), 30 deletions(-)
>
> diff --git a/monitor.c b/monitor.c
> index 76a8207..7653e0b 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2026,7 +2026,7 @@ static void tlb_info_32(Monitor *mon, CPUState *env)
>
> pgd = env->cr[3] & ~0xfff;
> for(l1 = 0; l1 < 1024; l1++) {
> -cpu_physical_memory_read(pgd + l1 * 4, (uint8_t *)&pde, 4);
> +cpu_physical_memory_read(pgd + l1 * 4, &pde, 4);
> pde = le32_to_cpu(pde);
> if (pde & PG_PRESENT_MASK) {
> if ((pde & PG_PSE_MASK) && (env->cr[4] & CR4_PSE_MASK)) {
> @@ -2034,8 +2034,7 @@ static void tlb_info_32(Monitor *mon, CPUState *env)
> print_pte(mon, (l1 << 22), pde, ~((1 << 21) - 1));
> } else {
> for(l2 = 0; l2 < 1024; l2++) {
> -cpu_physical_memory_read((pde & ~0xfff) + l2 * 4,
> - (uint8_t *)&pte, 4);
> +cpu_physical_memory_read((pde & ~0xfff) + l2 * 4, &pte,
> 4);
> pte = le32_to_cpu(pte);
> if (pte & PG_PRESENT_MASK) {
> print_pte(mon, (l1 << 22) + (l2 << 12),
> @@ -2056,13 +2055,12 @@ static void tlb_info_pae32(Monitor *mon, CPUState
> *env)
>
> pdp_addr = env->cr[3] & ~0x1f;
> for (l1 = 0; l1 < 4; l1++) {
> -cpu_physical_memory_read(pdp_addr + l1 * 8, (uint8_t *)&pdpe, 8);
> +cpu_physical_memory_read(pdp_addr + l1 * 8, &pdpe, 8);
> pdpe = le64_to_cpu(pdpe);
> if (pdpe & PG_PRESENT_MASK) {
> pd_addr = pdpe & 0x3f000ULL;
> for (l2 = 0; l2 < 512; l2++) {
> -cpu_physical_memory_read(pd_addr + l2 * 8,
> - (uint8_t *)&pde, 8);
> +cpu_physical_memory_read(pd_addr + l2 * 8, &pde, 8);
> pde = le64_to_cpu(pde);
> if (pde & PG_PRESENT_MASK) {
> if (pde & PG_PSE_MASK) {
> @@ -2072,8 +2070,7 @@ static void tlb_info_pae32(Monitor *mon, CPUState *env)
> } else {
> pt_addr = pde & 0x3f000ULL;
> for (l3 = 0; l3 < 512; l3++) {
> -cpu_physical_memory_read(pt_addr + l3 * 8,
> - (uint8_t *)&pte, 8);
> +cpu_physical_memory_read(pt_addr + l3 * 8, &pte,
> 8);
> pte = le64_to_cpu(pte);
> if (pte & PG_PRESENT_MASK) {
> print_pte(mon, (l1 << 30 ) + (l2 << 21)
> @@ -2098,13 +2095,12 @@ static void tlb_info_64(Monitor *mon, CPUState *env)
>
> pml4_addr = env->cr[3] & 0x3f000ULL;
> for (l1 = 0; l1 < 512; l1++) {
> -cpu_physical_memory_read(pml4_addr + l1 * 8, (uint8_t *)&pml4e, 8);
> +cpu_physical_memory_read(pml4_addr + l1 * 8, &pml4e, 8);
> pml4e = le64_to_cpu(pml4e);
> if (pml4e & PG_PRESENT_MASK) {
> pdp_addr = pml4e & 0x3f000ULL;
> for (l2 = 0; l2 < 512; l2++) {
> -cpu_physical_memory_read(pdp_addr + l2 * 8, (uint8_t *)&pdpe,
> - 8);
> +cpu_physical_memory_read(pdp_addr + l2 * 8, &pdpe, 8);
> pdpe = le64_to_cpu(pdpe);
> if (pdpe & PG_PRESENT_MASK) {
> if (pdpe & PG_PSE_MASK) {
> @@ -2114,8 +2110,7 @@ static void tlb_info_64(Monitor *mon, CPUState *env)
> } else {
> pd_addr = pdpe & 0x3f000ULL;
> for (l3 = 0; l3 < 512; l3++) {
> -cpu_physical_memory_read(pd_addr + l3 * 8,
> - (uint8_t *)&pde, 8);
> +cpu_physical_memory_read(pd_addr + l3 * 8, &pde,
> 8);
> pde = le64_to_cpu(pde);
> if (pde & PG_PRESENT_MASK) {
> if (pde & PG_PSE_MASK) {
> @@ -2128,8 +2123,7 @@ static void tlb_info_64(Monitor *mon, CPUState *env)
> for (l4 = 0; l4 < 512; l4++) {
> cpu_physical_memory_read(pt_addr
> + l4 * 8,
> - (uint8_t
> *)&pte,
> - 8);
> +
Re: [Qemu-devel] [PATCH] [arm m68k] move helpers.h to helper.h
On Sun, Mar 27, 2011 at 09:42:23PM +0200, Lluís wrote: > This provides a consistent naming scheme across all targets. > > Signed-off-by: Lluís Vilanova > --- > target-arm/helper.c|2 > target-arm/helper.h| 475 > > target-arm/helpers.h | 475 > > target-arm/iwmmxt_helper.c |2 > target-arm/neon_helper.c |2 > target-arm/op_helper.c |2 > target-arm/translate.c |6 - > target-m68k/helper.c |2 > target-m68k/helper.h | 54 + > target-m68k/helpers.h | 54 - > target-m68k/op_helper.c|2 > target-m68k/translate.c|6 - > 12 files changed, 541 insertions(+), 541 deletions(-) > create mode 100644 target-arm/helper.h > delete mode 100644 target-arm/helpers.h > create mode 100644 target-m68k/helper.h > delete mode 100644 target-m68k/helpers.h Could you please separate the arm and m68k parts into different patches? In that case, I'll apply the arm part. > diff --git a/target-arm/helper.c b/target-arm/helper.c > index 78f3d39..5260e13 100644 > --- a/target-arm/helper.c > +++ b/target-arm/helper.c > @@ -5,7 +5,7 @@ > #include "cpu.h" > #include "exec-all.h" > #include "gdbstub.h" > -#include "helpers.h" > +#include "helper.h" > #include "qemu-common.h" > #include "host-utils.h" > #if !defined(CONFIG_USER_ONLY) > diff --git a/target-arm/helper.h b/target-arm/helper.h > new file mode 100644 > index 000..bd6977c > --- /dev/null > +++ b/target-arm/helper.h > @@ -0,0 +1,475 @@ > +#include "def-helper.h" > + > +DEF_HELPER_1(clz, i32, i32) > +DEF_HELPER_1(sxtb16, i32, i32) > +DEF_HELPER_1(uxtb16, i32, i32) > + > +DEF_HELPER_2(add_setq, i32, i32, i32) > +DEF_HELPER_2(add_saturate, i32, i32, i32) > +DEF_HELPER_2(sub_saturate, i32, i32, i32) > +DEF_HELPER_2(add_usaturate, i32, i32, i32) > +DEF_HELPER_2(sub_usaturate, i32, i32, i32) > +DEF_HELPER_1(double_saturate, i32, s32) > +DEF_HELPER_2(sdiv, s32, s32, s32) > +DEF_HELPER_2(udiv, i32, i32, i32) > +DEF_HELPER_1(rbit, i32, i32) > +DEF_HELPER_1(abs, i32, i32) > + > +#define PAS_OP(pfx) \ > +DEF_HELPER_3(pfx ## add8, i32, i32, i32, ptr) \ > +DEF_HELPER_3(pfx ## sub8, i32, i32, i32, ptr) \ > +DEF_HELPER_3(pfx ## sub16, i32, i32, i32, ptr) \ > +DEF_HELPER_3(pfx ## add16, i32, i32, i32, ptr) \ > +DEF_HELPER_3(pfx ## addsubx, i32, i32, i32, ptr) \ > +DEF_HELPER_3(pfx ## subaddx, i32, i32, i32, ptr) > + > +PAS_OP(s) > +PAS_OP(u) > +#undef PAS_OP > + > +#define PAS_OP(pfx) \ > +DEF_HELPER_2(pfx ## add8, i32, i32, i32) \ > +DEF_HELPER_2(pfx ## sub8, i32, i32, i32) \ > +DEF_HELPER_2(pfx ## sub16, i32, i32, i32) \ > +DEF_HELPER_2(pfx ## add16, i32, i32, i32) \ > +DEF_HELPER_2(pfx ## addsubx, i32, i32, i32) \ > +DEF_HELPER_2(pfx ## subaddx, i32, i32, i32) > +PAS_OP(q) > +PAS_OP(sh) > +PAS_OP(uq) > +PAS_OP(uh) > +#undef PAS_OP > + > +DEF_HELPER_2(ssat, i32, i32, i32) > +DEF_HELPER_2(usat, i32, i32, i32) > +DEF_HELPER_2(ssat16, i32, i32, i32) > +DEF_HELPER_2(usat16, i32, i32, i32) > + > +DEF_HELPER_2(usad8, i32, i32, i32) > + > +DEF_HELPER_1(logicq_cc, i32, i64) > + > +DEF_HELPER_3(sel_flags, i32, i32, i32, i32) > +DEF_HELPER_1(exception, void, i32) > +DEF_HELPER_0(wfi, void) > + > +DEF_HELPER_2(cpsr_write, void, i32, i32) > +DEF_HELPER_0(cpsr_read, i32) > + > +DEF_HELPER_3(v7m_msr, void, env, i32, i32) > +DEF_HELPER_2(v7m_mrs, i32, env, i32) > + > +DEF_HELPER_3(set_cp15, void, env, i32, i32) > +DEF_HELPER_2(get_cp15, i32, env, i32) > + > +DEF_HELPER_3(set_cp, void, env, i32, i32) > +DEF_HELPER_2(get_cp, i32, env, i32) > + > +DEF_HELPER_2(get_r13_banked, i32, env, i32) > +DEF_HELPER_3(set_r13_banked, void, env, i32, i32) > + > +DEF_HELPER_1(get_user_reg, i32, i32) > +DEF_HELPER_2(set_user_reg, void, i32, i32) > + > +DEF_HELPER_1(vfp_get_fpscr, i32, env) > +DEF_HELPER_2(vfp_set_fpscr, void, env, i32) > + > +DEF_HELPER_3(vfp_adds, f32, f32, f32, env) > +DEF_HELPER_3(vfp_addd, f64, f64, f64, env) > +DEF_HELPER_3(vfp_subs, f32, f32, f32, env) > +DEF_HELPER_3(vfp_subd, f64, f64, f64, env) > +DEF_HELPER_3(vfp_muls, f32, f32, f32, env) > +DEF_HELPER_3(vfp_muld, f64, f64, f64, env) > +DEF_HELPER_3(vfp_divs, f32, f32, f32, env) > +DEF_HELPER_3(vfp_divd, f64, f64, f64, env) > +DEF_HELPER_1(vfp_negs, f32, f32) > +DEF_HELPER_1(vfp_negd, f64, f64) > +DEF_HELPER_1(vfp_abss, f32, f32) > +DEF_HELPER_1(vfp_absd, f64, f64) > +DEF_HELPER_2(vfp_sqrts, f32, f32, env) > +DEF_HELPER_2(vfp_sqrtd, f64, f64, env) > +DEF_HELPER_3(vfp_cmps, void, f32, f32, env) > +DEF_HELPER_3(vfp_cmpd, void, f64, f64, env) > +DEF_HELPER_3(vfp_cmpes, void, f32, f32, env) > +DEF_HELPER_3(vfp_cmped, void, f64, f64, env) > + > +DEF_HELPER_2(vfp_fcvtds, f64, f32, env) > +DEF_HELPER_2(vfp_fcvtsd, f32, f64, env) > + > +DEF_HELPER_2(vfp_uitos, f32, f32, env) > +DEF_HELPER_2(vfp_uitod, f64, f32, env) > +DEF_HELPER_2(vfp_sitos, f32, f32, env) > +DEF_HELPER_2(vfp_sitod, f64, f32, e
Re: [Qemu-devel] [PATCH] Fix conversions from pointer to tcg_target_long
On Sat, Apr 02, 2011 at 01:36:31PM +0200, Stefan Weil wrote:
> tcg_gen_exit_tb takes a parameter of type tcg_target_long,
> so the type casts of pointer to long should be replaced by
> type casts of pointer to tcg_target_long (suggested by Blue Swirl).
>
> These changes are needed for build environments where
> sizeof(long) != sizeof(void *), especially for w64.
>
> Signed-off-by: Stefan Weil
> ---
> gen-icount.h |2 +-
> target-alpha/translate.c |6 +++---
> target-arm/translate.c|2 +-
> target-cris/translate.c |2 +-
> target-i386/translate.c |2 +-
> target-lm32/translate.c |2 +-
> target-m68k/translate.c |2 +-
> target-microblaze/translate.c |2 +-
> target-mips/translate.c |2 +-
> target-ppc/translate.c|2 +-
> target-sh4/translate.c|2 +-
> target-sparc/translate.c |2 +-
> 12 files changed, 14 insertions(+), 14 deletions(-)
Thanks, applied.
> diff --git a/gen-icount.h b/gen-icount.h
> index 8879da6..5fb3829 100644
> --- a/gen-icount.h
> +++ b/gen-icount.h
> @@ -29,7 +29,7 @@ static void gen_icount_end(TranslationBlock *tb, int
> num_insns)
> if (use_icount) {
> *icount_arg = num_insns;
> gen_set_label(icount_label);
> -tcg_gen_exit_tb((long)tb + 2);
> +tcg_gen_exit_tb((tcg_target_long)tb + 2);
> }
> }
>
> diff --git a/target-alpha/translate.c b/target-alpha/translate.c
> index 3a1c625..96e922b 100644
> --- a/target-alpha/translate.c
> +++ b/target-alpha/translate.c
> @@ -398,7 +398,7 @@ static ExitStatus gen_bdirect(DisasContext *ctx, int ra,
> int32_t disp)
> } else if (use_goto_tb(ctx, dest)) {
> tcg_gen_goto_tb(0);
> tcg_gen_movi_i64(cpu_pc, dest);
> -tcg_gen_exit_tb((long)ctx->tb);
> +tcg_gen_exit_tb((tcg_target_long)ctx->tb);
> return EXIT_GOTO_TB;
> } else {
> tcg_gen_movi_i64(cpu_pc, dest);
> @@ -417,12 +417,12 @@ static ExitStatus gen_bcond_internal(DisasContext *ctx,
> TCGCond cond,
>
> tcg_gen_goto_tb(0);
> tcg_gen_movi_i64(cpu_pc, ctx->pc);
> -tcg_gen_exit_tb((long)ctx->tb);
> +tcg_gen_exit_tb((tcg_target_long)ctx->tb);
>
> gen_set_label(lab_true);
> tcg_gen_goto_tb(1);
> tcg_gen_movi_i64(cpu_pc, dest);
> -tcg_gen_exit_tb((long)ctx->tb + 1);
> +tcg_gen_exit_tb((tcg_target_long)ctx->tb + 1);
>
> return EXIT_GOTO_TB;
> } else {
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 39512bc..b3f82c7 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -3394,7 +3394,7 @@ static inline void gen_goto_tb(DisasContext *s, int n,
> uint32_t dest)
> if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK)) {
> tcg_gen_goto_tb(n);
> gen_set_pc_im(dest);
> -tcg_gen_exit_tb((long)tb + n);
> +tcg_gen_exit_tb((tcg_target_long)tb + n);
> } else {
> gen_set_pc_im(dest);
> tcg_gen_exit_tb(0);
> diff --git a/target-cris/translate.c b/target-cris/translate.c
> index b4648a0..1c03fa5 100644
> --- a/target-cris/translate.c
> +++ b/target-cris/translate.c
> @@ -596,7 +596,7 @@ static void gen_goto_tb(DisasContext *dc, int n,
> target_ulong dest)
> if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK)) {
> tcg_gen_goto_tb(n);
> tcg_gen_movi_tl(env_pc, dest);
> - tcg_gen_exit_tb((long)tb + n);
> +tcg_gen_exit_tb((tcg_target_long)tb + n);
> } else {
> tcg_gen_movi_tl(env_pc, dest);
> tcg_gen_exit_tb(0);
> diff --git a/target-i386/translate.c b/target-i386/translate.c
> index c008450..7d1340e 100644
> --- a/target-i386/translate.c
> +++ b/target-i386/translate.c
> @@ -2274,7 +2274,7 @@ static inline void gen_goto_tb(DisasContext *s, int
> tb_num, target_ulong eip)
> /* jump to same page: we can use a direct jump */
> tcg_gen_goto_tb(tb_num);
> gen_jmp_im(eip);
> -tcg_gen_exit_tb((long)tb + tb_num);
> +tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
> } else {
> /* jump to another page: currently not optimized */
> gen_jmp_im(eip);
> diff --git a/target-lm32/translate.c b/target-lm32/translate.c
> index 666d5f4..efc9b5a 100644
> --- a/target-lm32/translate.c
> +++ b/target-lm32/translate.c
> @@ -138,7 +138,7 @@ static void gen_goto_tb(DisasContext *dc, int n,
> target_ulong dest)
> likely(!dc->singlestep_enabled)) {
> tcg_gen_goto_tb(n);
> tcg_gen_movi_tl(cpu_pc, dest);
> -tcg_gen_exit_tb((long)tb + n);
> +tcg_gen_exit_tb((tcg_target_long)tb + n);
> } else {
> tcg_gen_movi_tl(cpu_pc, dest);
> if (dc->singlestep_enabled) {
> diff --git a/target-m68k/translate.c b/target-m68k/translate.c
> index 6f72a2b..038c0af 100644
> --- a/target-m68k
[Qemu-devel] qemu_malloc failing
Hi,
I'm trying to investigate a bug (crash) that I see when attaching a USB device
(a UVC webcam) from the host to the guest.
I'm running it as:
sudo gdb --args /opt/bin/qemu -hda ubuntu-test -name kubuntu-qemu -usb -device
usb-tablet -m 1024 -serial stdio -usbdevice host:0c45:6450
(I've tried running with -m 512 too, not discernibly different).
Host and guest are the same - kubuntu 10.10. The device works fine on the host.
The guest runs for a while, and has no ill-effects (that I've seen) until I try
to use the webcam. If I open the device (using cheese or luvcview), I see some
traffic, then qemu segfaults:
Program received signal SIGSEGV, Segmentation fault.
0x75a4e66c in malloc_consolidate (av=0x75d55e40) at malloc.c:5161
5161malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0 0x75a4e66c in malloc_consolidate (av=0x75d55e40) at
malloc.c:5161
#1 0x75a51e82 in _int_malloc (av=0x75d55e40, bytes=2128) at
malloc.c:4373
#2 0x75a5338e in __libc_malloc (bytes=2128) at malloc.c:3660
#3 0x0042b3d6 in qemu_malloc (size=2128) at qemu-malloc.c:49
#4 0x0056100f in uhci_async_alloc (s=0x15dcc10) at
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:167
#5 0x005620d4 in uhci_handle_td (s=0x15dcc10, addr=684474656,
td=0x7fffdf80, int_mask=0x7fffdfac) at
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:808
#6 0x00562665 in uhci_process_frame (s=0x15dcc10) at
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:1007
#7 0x005628a8 in uhci_frame_timer (opaque=0x15dcc10) at
/home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:1092
#8 0x004da94c in qemu_run_timers (clock=0x1171ff0) at qemu-timer.c:505
#9 0x004dac0c in qemu_run_all_timers () at qemu-timer.c:616
#10 0x005484c2 in main_loop_wait (nonblocking=1) at
/home/bradh/qemu-codingstyle.git/vl.c:1324
#11 0x00548549 in main_loop () at
/home/bradh/qemu-codingstyle.git/vl.c:1365
#12 0x0054c725 in main (argc=14, argv=0x7fffe648,
envp=0x7fffe6c0) at /home/bradh/qemu-codingstyle.git/vl.c:3195
Line 167 in hw/usb-uhci.c is in in static UHCIAsync *uhci_async_alloc(UHCIState
*s)
It looks like:
UHCIAsync *async = qemu_malloc(sizeof(UHCIAsync));
UHCIState is fairly large, so the size looks possible:
typedef struct UHCIState {
PCIDevice dev;
USBBus bus;
uint16_t cmd; /* cmd register */
uint16_t status;
uint16_t intr; /* interrupt enable register */
uint16_t frnum; /* frame number */
uint32_t fl_base_addr; /* frame list base address */
uint8_t sof_timing;
uint8_t status2; /* bit 0 and 1 are used to generate UHCI_STS_USBINT */
int64_t expire_time;
QEMUTimer *frame_timer;
UHCIPort ports[NB_PORTS];
/* Interrupts that should be raised at the end of the current frame. */
uint32_t pending_int_mask;
/* Active packets */
UHCIAsync *async_pending;
UHCIAsync *async_pool;
uint8_t num_ports_vmstate;
} UHCIState;
Line 49 in qemu_malloc.c is in void *qemu_malloc(size_t size).
It looks like.
ptr = qemu_oom_check(malloc(size ? size : 1));
So I guess malloc is failing. However I don't see how / why. The host is a
laptop
machine with 6G RAM, and it appears to remain quite responsive.
Any suggestions on how to proceed with debugging this?
Brad
Re: [Qemu-devel] qemu_malloc failing
Hi... On Sun, Apr 10, 2011 at 09:08, Brad Hards wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x75a4e66c in malloc_consolidate (av=0x75d55e40) at malloc.c:5161 > 5161 malloc.c: No such file or directory. > in malloc.c > (gdb) bt > #0 0x75a4e66c in malloc_consolidate (av=0x75d55e40) at > malloc.c:5161 > #1 0x75a51e82 in _int_malloc (av=0x75d55e40, bytes=2128) at > malloc.c:4373 > #2 0x75a5338e in __libc_malloc (bytes=2128) at malloc.c:3660 > #3 0x0042b3d6 in qemu_malloc (size=2128) at qemu-malloc.c:49 > #4 0x0056100f in uhci_async_alloc (s=0x15dcc10) at > /home/bradh/qemu-codingstyle.git/hw/usb-uhci.c:167 looking at: http://www.linuxquestions.org/questions/programming-9/segfault-in-malloc_consolidate-363048/ and http://www.linuxquestions.org/questions/linux-general-1/malloc_consolidate-757663/ I feel that it's somekind double free or data overwriting the malloc metadata thus causing trouble during memory block coalescing... First thing I suggest is to check if malloc() is always followed by proper free() and then see how much we really fill data into that allocated block (think about malloc exploit explained in Phrack...) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Re: [Qemu-devel] [PATCH 1/3] cpu-common: Modify cpu_physical_memory_read and cpu_physical_memory_write
Am 10.04.2011 00:37, schrieb Aurelien Jarno:
On Sat, Mar 26, 2011 at 09:06:55PM +0100, Stefan Weil wrote:
A lot of calls don't operate on bytes but on words or on structured data.
So instead of a pointer to uint8_t, a void pointer is the better choice.
This allows removing many type casts.
(Some very early implementations of memcpy used char pointers
which were replaced by void pointers for the same reason).
Cc: Blue Swirl
Signed-off-by: Stefan Weil
---
cpu-common.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index ef4e8da..f44a2b0 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -68,12 +68,12 @@ void cpu_unregister_io_memory(int table_address);
void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
int len, int is_write);
static inline void cpu_physical_memory_read(target_phys_addr_t addr,
- uint8_t *buf, int len)
+ void *buf, int len)
{
cpu_physical_memory_rw(addr, buf, len, 0);
}
static inline void cpu_physical_memory_write(target_phys_addr_t addr,
- const uint8_t *buf, int len)
+ const void *buf, int len)
{
cpu_physical_memory_rw(addr, (uint8_t *)buf, len, 1);
We might want to also do the change here, that is replacing (uint8_t *)
to (void *). Also instead of doing half the job, it would be nice to do
the same changes on cpu_physical_memory_rw().
Hello Aurelien,
this type cast removes the const attribute from buf, so it is needed.
And I did not change cpu_physical_memory_rw (and some more
functions) because the gain is small: there are only 10 type casts
used with cpu_physical_memory_rw, and at least some of them
are needed because of const attributes.
I don't like type casts which remove the const attribute, so there
should be additional changes. But I don't think that it would be a
good idea to mix them with this patch.
Re: [Qemu-devel] [PATCH 4/4] vnc: Limit r/w access to size of allocated memory
Am 10.04.2011 00:17, schrieb Aurelien Jarno:
On Mon, Mar 21, 2011 at 09:34:38AM +0100, Corentin Chary wrote:
From: Stefan Weil
This fixes memory reads and writes which exceeded the upper limit
of allocated memory vd->guest.ds->data and vd->server->data.
Cc: Anthony Liguori
Signed-off-by: Stefan Weil
Signed-off-by: Corentin Chary
---
ui/vnc.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 90b6384..3138053 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2414,6 +2414,9 @@ static int
vnc_refresh_server_surface(VncDisplay *vd)
* Update server dirty map.
*/
cmp_bytes = 16 * ds_get_bytes_per_pixel(vd->ds);
+ if (cmp_bytes > vd->ds->surface->linesize) {
+ cmp_bytes = vd->ds->surface->linesize;
+ }
What about using ds_get_linesize(vd->ds) instead?
Yes, that's better. Please either change the two lines, or
wait until I have sent a new version of the patch.
The patch should be applied to stable, too.
Thanks,
Stefan
Re: [Qemu-devel] qemu_malloc failing
On Sun, Apr 10, 2011 at 3:08 AM, Brad Hards wrote: > #3 0x0042b3d6 in qemu_malloc (size=2128) at qemu-malloc.c:49 It's only slightly more than 2 KB. When malloc(3) fails it returns NULL, it doesn't crash. As Mulyadi suggested, this looks like heap corruption. If you have no idea where the problem is coming from, you might like to try valgrind(1). Stefan
