[Qemu-devel] The reason behind block linking constraint?
Hi, all
I am trying to figure out why QEMU put some constraints on block
linking (chaining). Take x86 as an example, there are two places
put constraints on block linking, gen_goto_tb and cpu_exec.
- gen_goto_tb (target-i386/translate.c) ---
/* NOTE: we handle the case where the TB spans two pages here */
if ((pc TARGET_PAGE_MASK) == (tb-pc TARGET_PAGE_MASK) ||
(pc TARGET_PAGE_MASK) == ((s-pc - 1) TARGET_PAGE_MASK)) {
/* jump to same page: we can use a direct jump */
tcg_gen_goto_tb(tb_num);
gen_jmp_im(eip);
tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
} else {
/* jump to another page: currently not optimized */
gen_jmp_im(eip);
gen_eob(s);
}
---
--- cpu_exec (cpu-exec.c) -
/* see if we can patch the calling TB. When the TB
spans two pages, we cannot safely do a direct
jump. */
if (next_tb != 0 tb-page_addr[1] == -1) {
tb_add_jump((TranslationBlock *)(next_tb ~3), next_tb 3, tb);
}
---
Is it just because we cannot optimize block linking which crosses page
boundary, or there are some correctness/safety issues should be considered?
I did some experiments myself. First, I removed the if-else condition
in gen_goto_tb (always go to if branch) and leave cpu_exec alone. In this
case, user mode works fine, but system mode crashes while booting linux.
Then, I removed the tb-page_addr[1] check and leave gen_goto_tb
alone. This time, both user mode and system mode works fine. I use the
disk image and user mode tests downloaded from the website as the test
case.
Could someone kindly explain why there are constraints on block
linking? Thanks!
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Regards, Laurent Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove toea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low
Re: [Qemu-devel] The reason behind block linking constraint?
Hi, all
I am trying to figure out why QEMU put some constraints on block
linking (chaining). Take x86 as an example, there are two places
put constraints on block linking, gen_goto_tb and cpu_exec.
- gen_goto_tb (target-i386/translate.c) ---
/* NOTE: we handle the case where the TB spans two pages here */
if ((pc TARGET_PAGE_MASK) == (tb-pc TARGET_PAGE_MASK) ||
(pc TARGET_PAGE_MASK) == ((s-pc - 1) TARGET_PAGE_MASK)) {
/* jump to same page: we can use a direct jump */
tcg_gen_goto_tb(tb_num);
gen_jmp_im(eip);
tcg_gen_exit_tb((tcg_target_long)tb + tb_num);
} else {
/* jump to another page: currently not optimized */
gen_jmp_im(eip);
gen_eob(s);
}
---
--- cpu_exec (cpu-exec.c) -
/* see if we can patch the calling TB. When the TB
spans two pages, we cannot safely do a direct
jump. */
if (next_tb != 0 tb-page_addr[1] == -1) {
tb_add_jump((TranslationBlock *)(next_tb ~3), next_tb 3, tb);
}
---
Is it just because we cannot optimize block linking which crosses page
boundary, or there are some correctness/safety issues should be considered?
If we link a TB with another TB from the different page, then the
second TB may disappear when the memory mapping changes and the
subsequent direct jump from the first TB will crash qemu.
I guess that this usually does not happen in usermode, because the
guest would not modify executable code memory mapping. However I
suppose that this is also possible.
--
Thanks.
-- Max
Re: [Qemu-devel] The reason behind block linking constraint?
If we link a TB with another TB from the different page, then the second TB may disappear when the memory mapping changes and the subsequent direct jump from the first TB will crash qemu. Perhaps the guest OS swap the second TB out of the guest memory, is it what you mean? I meant TLB change by e.g. tlb_set_page. If you change single page mapping then all TBs in that page will be gone. This may be the result of e.g. a page swapping, or a task switch. If there's no direct link between TBs then softmmu will be used during the target TB search and softmmu will generate an appropriate guest exception. See cpu_exec - tb_find_fast - tb_find_slow - get_page_addr_code. But if there is a direct link, then softmmu has no chance to do it. -- Thanks. -- Max
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? François.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Regards, Laurent
Re: [Qemu-devel] [PATCH] qemu-img: print error codes when convert fails
On Wed, Aug 17, 2011 at 08:40:57PM +0200, Kevin Wolf wrote: Am 17.08.2011 18:41, schrieb Stefan Hajnoczi: Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com Thanks, applied to the block branch. (But is it really helpful to include sector numbers in the error message? Especially since we're not reading/writing single sectors) The intention is that it would show suspicious sectors numbers, e.g. ~2 GB or ~4 GB. In the best case it saves a round-trip on a bug report. In the worst case the sector number is a distraction :). Stefan
[Qemu-devel] Serial port on virtual machines
Hi, I'm running VM on kvm-qemu hyper visor . I need to access the serail port on the VM , I tried the sample code to read/write com port but I get port error when ever I tried write something to the port(dev/ttyS0) . the same code work fine on the normal OS .. is it the same way as normal OS for accessing the serial port in vms ..?
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/17/2011 06:30 PM, Bryce Lanham wrote: Ugh, I'm sorry about that. This is why I should test before using unfamiliar tools. Someone suggested using git format-patch/git send-email instead of a big patch. That's definitely preferred actually, but you should look at breaking this into multiple logical/self-contained series for easier review/testing. Apologies, Bryce Lanham On Wed, Aug 17, 2011 at 5:35 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. Regards, Anthony Liguori Bryce Lanham Alexander Paramonov (1): linux-user: Signals processing is not thread-safe. Andreas Schwab (3): m68k: add cas m68k: define fcntl constants m68k: add DBcc instruction. Laurent Vivier (106): linux-user: add qemu-wrapper linux-user: define default cpu model in configure instead of linux-user/main.c linux-user: specify the cpu model during configure linux-user,m68k: display default cpu linux-user: define new environment variables linux-user: define a script to set binfmt using debian flavored tools linux-user: define default cpu model in configure instead of linux-user/main.c m68k: add tcg_gen_debug_insn_start() m68k: define m680x0 CPUs and features m68k: add missing accessing modes for some instructions. m68k: add Motorola 680x0 family common instructions. m68k: add Scc instruction with memory operand. m68k: add DBcc instruction. m68k: modify movem instruction to manage word m68k: add 64bit divide. m68k: add 32bit and 64bit multiply m68k: add word data size for suba/adda m68k: add fpu m68k: add byte, word and memory shift m68k: add byte, word and memory rotate. m68k: add bitfield_mem, bitfield_reg m68k: add variable offset/width to bitfield_reg/bitfield_mem m68k: add cas m68k: allow fpu to manage double data type. m68k: allow fpu to manage double data type with fmove toea m68k: add FScc instruction m68k: add single data type to gen_ea m68k: add linkl instruction m68k: Add fmovecr m68k: correct typo on f64_to_i32() return type. m68k: improve CC_OP_LOGIC m68k: correct neg condition code flags computation Correct invalid use of const void * with const uint8_t * m68k: add EA support for negx m68k: add abcd instruction m68k: add sbcd instruction mm68k: add nbcd instruction m68k: set X flag according size of operand Set X flag correctly for addsub, arith_im, addsubq. m68k: on 0 bit shift, don't update X flag m68k: improve addx instructions Add (byte, word) opsize Add memory access m68k: improve subx,negx instructions Add (byte, word) opsize Add memory access (subx) m68k: improve asl/asr evaluate correclty the missing V flag m68k: use read_imm1() when it is possible m68k: correct shift side effect for roxrl and roxll m68k: asl/asr, clear C flag if shift count is 0 m68k: lsl/lsr, clear C flag if shift count is 0 m68k: correct divs.w and divu.w m68k: correct flags with negl m68k: for bitfield opcodes, correct operands corruption m68k: Correct bfclr in register case. m68k-linux-user: add '--enable-emulop' m68k: correctly compute divsl m68k: correctly compute divul m68k: add m68030 definition m68k: remove dead code m68k: remove useless file m68k-qreg.h m68k: FPU rework (draft) m68k: some FPU debugging macros m68k: more tests m68k: correct compute gen_bitfield_cc() m68k: add fgetexp m68k: add fscale m68k: correct addsubq m68k: add fetox and flogn m68k: initialize FRegs, define pickNaN() m68k: correct cmpa comparison datatype m68k: add flog10 m68k: add cmpm instruction m68k: add ftwotox instruction m68k: better fpu traces m68k: register source operand is always in extended size m68k: add facos instruction m68k: add ftan instruction m68k: add fsin instruction m68k: add fcos instruction m68k: correct fpcr update m68k: add fmod instruction m68k: flush flags before negx instruction. m68k: correct fmovemx FP registers order. m68k: add fatan instruction m68k: correct bfins instruction m68k: fcmp correctly compares infinity. m68k: allows bfins to manage correctly width = 32 m68k: add ftentox instruction m68k: correctly define and manage NaN m68k: don't call gdb_register_coprocessor() twice. m68k: gdb FP registers are 96 bits m68k: add exg instruction m68k: define floatx80_default_inf_high and floatx80_default_inf_low m68k: add bkpt instruction m68k: correctly convert floatx80-long double m68k: use expl() to compute exp_FP0()
Re: [Qemu-devel] [PATCH 04/14] gus: Convert to isa_register_old_portio_list.
On Tue, 16 Aug 2011, Richard Henderson wrote: Signed-off-by: Richard Henderson r...@twiddle.net Cc: malc av1...@comtv.ru This patchset breaks both gus and sb16 for me. [..snip..] -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
This makes the tracing infrastructure available to users of g_new().
Signed-off-by: Avi Kivity a...@redhat.com
---
qemu-common.h |1 +
qemu-malloc.c | 15 +++
vl.c |1 +
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/qemu-common.h b/qemu-common.h
index 74d5c4b..fbe2de0 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -180,6 +180,7 @@ const char *path(const char *pathname);
#define qemu_isascii(c)isascii((unsigned char)(c))
#define qemu_toascii(c)toascii((unsigned char)(c))
+void qemu_malloc_init(void);
void *qemu_oom_check(void *ptr);
void *qemu_malloc(size_t size);
void *qemu_realloc(void *ptr, size_t size);
diff --git a/qemu-malloc.c b/qemu-malloc.c
index b9b3851..8b0c1ec 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -24,6 +24,21 @@
#include qemu-common.h
#include trace.h
#include stdlib.h
+#include glib.h
+
+static GMemVTable gmemvtable = {
+.malloc = qemu_malloc,
+.realloc = qemu_realloc,
+.free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+g_mem_set_vtable(gmemvtable);
+}
void qemu_free(void *ptr)
{
diff --git a/vl.c b/vl.c
index c714127..7c4f8da 100644
--- a/vl.c
+++ b/vl.c
@@ -2106,6 +2106,7 @@ int main(int argc, char **argv, char **envp)
atexit(qemu_run_exit_notifiers);
error_set_progname(argv[0]);
+qemu_malloc_init();
init_clocks();
--
1.7.6
[Qemu-devel] VMState assertion for USB devices on multiple buses
I've been experimenting with multiple USB2 buses, and device physical port addressing. It seems if you have 2 devices of the same type on the same port, but in different buses, you get a bogus VMState assertion failure # qemu-system-x86_64 \ -nodefconfig -nodefaults \ -vnc 127.0.0.1:0 -vga cirrus -monitor stdio \ -device ich9-usb-ehci1,addr=1d.7,multifunction=on,id=ehci0 \ -device ich9-usb-uhci1,addr=1d.0,multifunction=on,id=uhci0-1,masterbus=ehci0.0,firstport=0 \ -device ich9-usb-uhci2,addr=1d.1,multifunction=on,id=uhci0-2,masterbus=ehci0.0,firstport=2 \ -device ich9-usb-uhci3,addr=1d.2,multifunction=on,id=uhci0-3,masterbus=ehci0.0,firstport=4 \ -device usb-tablet,bus=ehci0.0,port=1,id=t1 \ -device ich9-usb-ehci1,addr=1c.7,multifunction=on,id=ehci1 \ -device ich9-usb-uhci1,addr=1c.0,multifunction=on,id=uhci1-1,masterbus=ehci1.0,firstport=0 \ -device ich9-usb-uhci2,addr=1c.1,multifunction=on,id=uhci1-2,masterbus=ehci1.0,firstport=2 \ -device ich9-usb-uhci3,addr=1c.2,multifunction=on,id=uhci1-3,masterbus=ehci1.0,firstport=4 \ -device usb-tablet,bus=ehci1.0,port=1,id=t2 *** EHCI support is under development *** *** EHCI support is under development *** qemu-system-x86_64: savevm.c:1260: vmstate_register_with_alias_id: Assertion `!se-compat || se-instance_id == 0' failed. Aborted If I have a CCID on one bus, and tablet on the other it works # qemu-system-x86_64 \ -nodefconfig -nodefaults \ -vnc 127.0.0.1:0 -vga cirrus -monitor stdio \ -device ich9-usb-ehci1,addr=1d.7,multifunction=on,id=ehci0 \ -device ich9-usb-uhci1,addr=1d.0,multifunction=on,id=uhci0-1,masterbus=ehci0.0,firstport=0 \ -device ich9-usb-uhci2,addr=1d.1,multifunction=on,id=uhci0-2,masterbus=ehci0.0,firstport=2 \ -device ich9-usb-uhci3,addr=1d.2,multifunction=on,id=uhci0-3,masterbus=ehci0.0,firstport=4 \ -device usb-tablet,bus=ehci0.0,port=1,id=t1 \ -device ich9-usb-ehci1,addr=1c.7,multifunction=on,id=ehci1 \ -device ich9-usb-uhci1,addr=1c.0,multifunction=on,id=uhci1-1,masterbus=ehci1.0,firstport=0 \ -device ich9-usb-uhci2,addr=1c.1,multifunction=on,id=uhci1-2,masterbus=ehci1.0,firstport=2 \ -device ich9-usb-uhci3,addr=1c.2,multifunction=on,id=uhci1-3,masterbus=ehci1.0,firstport=4 \ -device usb-ccid,bus=ehci1.0,port=1,id=t2 But if I have 2 CCID devices, then I see failure again # qemu-system-x86_64 \ -nodefconfig -nodefaults \ -vnc 127.0.0.1:0 -vga cirrus -monitor stdio \ -device ich9-usb-ehci1,addr=1d.7,multifunction=on,id=ehci0 \ -device ich9-usb-uhci1,addr=1d.0,multifunction=on,id=uhci0-1,masterbus=ehci0.0,firstport=0 \ -device ich9-usb-uhci2,addr=1d.1,multifunction=on,id=uhci0-2,masterbus=ehci0.0,firstport=2 \ -device ich9-usb-uhci3,addr=1d.2,multifunction=on,id=uhci0-3,masterbus=ehci0.0,firstport=4 \ -device usb-ccid,bus=ehci0.0,port=1,id=t1 \ -device ich9-usb-ehci1,addr=1c.7,multifunction=on,id=ehci1 \ -device ich9-usb-uhci1,addr=1c.0,multifunction=on,id=uhci1-1,masterbus=ehci1.0,firstport=0 \ -device ich9-usb-uhci2,addr=1c.1,multifunction=on,id=uhci1-2,masterbus=ehci1.0,firstport=2 \ -device ich9-usb-uhci3,addr=1c.2,multifunction=on,id=uhci1-3,masterbus=ehci1.0,firstport=4 \ -device usb-ccid,bus=ehci1.0,port=1,id=t2 *** EHCI support is under development *** *** EHCI support is under development *** qemu-system-x86_64: savevm.c:1260: vmstate_register_with_alias_id: Assertion `!se-compat || se-instance_id == 0' failed. Aborted AFAICT, the problem is that the 'se-idstr' field in the SaveStateEntry struct is not getting a unique enough value. Both the USB devices get idstr named 1/usb-ccid, which IIUC is a combination of the device type and the port number. IMHO, it needs to have the USB bus name in there too eg. in this example it should have been ehci0.0/1/usb-ccid ehci1.0/1/usb-ccid Regrads, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [Bug 567380] Re: qemu-img fails to create images = 4G
Confirmed under Win 7 64-bit. Also does same thing on v10.6, v11.1, v12.1 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/567380 Title: qemu-img fails to create images = 4G Status in QEMU: Incomplete Bug description: On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created. qemu-img create foo.img 4G To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/567380/+subscriptions
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi Laurent, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. He is! xD Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. We only lack the 68k cpu (oh! your patches!!!) and the glue :p Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!)
[Qemu-devel] [PATCH v2 0/4] ppc: booke206: KVM MMU API and info tlb
For this functionality to work with KVM, this kernel patch is required: http://www.spinics.net/lists/kvm-ppc/msg03053.html Scott Wood (4): kvm: update linux-headers kvm: ppc: booke206: use MMU API ppc: booke206: use MAV=2.0 TSIZE definition, fix 4G pages ppc: booke206: add info tlb support hmp-commands.hx |2 +- hw/ppce500_mpc8544ds.c |4 +- linux-headers/asm-powerpc/kvm.h | 54 +- linux-headers/asm-x86/kvm_para.h | 14 ++ linux-headers/linux/kvm.h| 41 +--- linux-headers/linux/kvm_para.h |1 + monitor.c|5 +- target-ppc/cpu.h |8 +++- target-ppc/helper.c | 93 +- target-ppc/kvm.c | 87 +++ 10 files changed, 291 insertions(+), 18 deletions(-) -- 1.7.6
[Qemu-devel] [PATCH v2 1/4] kvm: update linux-headers
Needed for PPC MMU API support.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2: new to v2
linux-headers/asm-powerpc/kvm.h | 54 -
linux-headers/asm-x86/kvm_para.h | 14 ++
linux-headers/linux/kvm.h| 41 +++-
linux-headers/linux/kvm_para.h |1 +
4 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index 777d307..874f23d 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -22,6 +22,10 @@
#include linux/types.h
+/* Select powerpc specific features in linux/kvm.h */
+#define __KVM_HAVE_SPAPR_TCE
+#define __KVM_HAVE_PPC_SMT
+
struct kvm_regs {
__u64 pc;
__u64 cr;
@@ -166,8 +170,8 @@ struct kvm_sregs {
} ppc64;
struct {
__u32 sr[16];
- __u64 ibat[8];
- __u64 dbat[8];
+ __u64 ibat[8];
+ __u64 dbat[8];
} ppc32;
} s;
struct {
@@ -272,4 +276,50 @@ struct kvm_guest_debug_arch {
#define KVM_INTERRUPT_UNSET-2U
#define KVM_INTERRUPT_SET_LEVEL-3U
+/* for KVM_CAP_SPAPR_TCE */
+struct kvm_create_spapr_tce {
+ __u64 liobn;
+ __u32 window_size;
+};
+
+/* for KVM_ALLOCATE_RMA */
+struct kvm_allocate_rma {
+ __u64 rma_size;
+};
+
+struct kvm_book3e_206_tlb_entry {
+ __u32 mas8;
+ __u32 mas1;
+ __u64 mas2;
+ __u64 mas7_3;
+};
+
+struct kvm_book3e_206_tlb_params {
+ /*
+* For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
+*
+* - The number of ways of TLB0 must be a power of two between 2 and
+* 16.
+* - TLB1 must be fully associative.
+* - The size of TLB0 must be a multiple of the number of ways, and
+* the number of sets must be a power of two.
+* - The size of TLB1 may not exceed 64 entries.
+* - TLB0 supports 4 KiB pages.
+* - The page sizes supported by TLB1 are as indicated by
+* TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
+* as returned by KVM_GET_SREGS.
+* - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
+* and tlb_ways[] must be zero.
+*
+* tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
+*
+* KVM will adjust TLBnCFG based on the sizes configured here,
+* though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
+* set to zero.
+*/
+ __u32 tlb_sizes[4];
+ __u32 tlb_ways[4];
+ __u32 reserved[8];
+};
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index 834d71e..f2ac46a 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -21,6 +21,7 @@
*/
#define KVM_FEATURE_CLOCKSOURCE23
#define KVM_FEATURE_ASYNC_PF 4
+#define KVM_FEATURE_STEAL_TIME 5
/* The last 8 bits are used to indicate how to interpret the flags field
* in pvclock structure. If no bits are set, all flags are ignored.
@@ -30,10 +31,23 @@
#define MSR_KVM_WALL_CLOCK 0x11
#define MSR_KVM_SYSTEM_TIME 0x12
+#define KVM_MSR_ENABLED 1
/* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
#define MSR_KVM_WALL_CLOCK_NEW 0x4b564d00
#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
+#define MSR_KVM_STEAL_TIME 0x4b564d03
+
+struct kvm_steal_time {
+ __u64 steal;
+ __u32 version;
+ __u32 flags;
+ __u32 pad[12];
+};
+
+#define KVM_STEAL_ALIGNMENT_BITS 5
+#define KVM_STEAL_VALID_BITS ((-1ULL (KVM_STEAL_ALIGNMENT_BITS + 1)))
+#define KVM_STEAL_RESERVED_MASK (((1 KVM_STEAL_ALIGNMENT_BITS) - 1 ) 1)
#define KVM_MAX_MMU_OP_BATCH 32
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index fc63b73..7d8a7f6 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -161,6 +161,7 @@ struct kvm_pit_config {
#define KVM_EXIT_NMI 16
#define KVM_EXIT_INTERNAL_ERROR 17
#define KVM_EXIT_OSI 18
+#define KVM_EXIT_PAPR_HCALL 19
/* For KVM_EXIT_INTERNAL_ERROR */
#define KVM_INTERNAL_ERROR_EMULATION 1
@@ -264,6 +265,11 @@ struct kvm_run {
struct {
__u64 gprs[32];
} osi;
+ struct {
+ __u64 nr;
+ __u64 ret;
+ __u64 args[9];
+ } papr_hcall;
/* Fix the size of the union. */
char padding[256];
};
@@ -457,7 +463,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_VAPIC 6
#define KVM_CAP_EXT_CPUID 7
#define
[Qemu-devel] [PATCH v2 2/4] kvm: ppc: booke206: use MMU API
Share the TLB array with KVM. This allows us to set the initial TLB
both on initial boot and reset, is useful for debugging, and could
eventually be used to support migration.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2 (was 1/3 in v1):
updated for kernel API change, removed kernel header ifdefs,
minor changes as requested
hw/ppce500_mpc8544ds.c |2 +
target-ppc/cpu.h |2 +
target-ppc/kvm.c | 87
3 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/hw/ppce500_mpc8544ds.c b/hw/ppce500_mpc8544ds.c
index b739ce2..3626e26 100644
--- a/hw/ppce500_mpc8544ds.c
+++ b/hw/ppce500_mpc8544ds.c
@@ -202,6 +202,8 @@ static void mmubooke_create_initial_mapping(CPUState *env,
tlb-mas2 = va TARGET_PAGE_MASK;
tlb-mas7_3 = pa TARGET_PAGE_MASK;
tlb-mas7_3 |= MAS3_UR | MAS3_UW | MAS3_UX | MAS3_SR | MAS3_SW | MAS3_SX;
+
+env-tlb_dirty = true;
}
static void mpc8544ds_cpu_reset(void *opaque)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 024eb6f..0e38d4f 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -919,6 +919,8 @@ struct CPUPPCState {
ppc_tlb_t tlb; /* TLB is optional. Allocate them only if needed*/
/* 403 dedicated access protection registers */
target_ulong pb[4];
+bool tlb_dirty; /* Set to non-zero when modifying TLB */
+bool kvm_sw_tlb; /* non-zero if KVM SW TLB API is active*/
#endif
/* Other registers */
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 21f35af7..1e1e5db 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -105,6 +105,54 @@ static int kvm_arch_sync_sregs(CPUState *cenv)
return kvm_vcpu_ioctl(cenv, KVM_SET_SREGS, sregs);
}
+/* Set up a shared TLB array with KVM */
+static int kvm_booke206_tlb_init(CPUState *env)
+{
+struct kvm_book3e_206_tlb_params params = {};
+struct kvm_config_tlb cfg = {};
+struct kvm_enable_cap encap = {};
+size_t array_len;
+unsigned int entries = 0;
+int ret, i;
+
+if (!kvm_enabled() ||
+!kvm_check_extension(env-kvm_state, KVM_CAP_SW_TLB)) {
+return 0;
+}
+
+assert(ARRAY_SIZE(params.tlb_sizes) == BOOKE206_MAX_TLBN);
+
+for (i = 0; i BOOKE206_MAX_TLBN; i++) {
+params.tlb_sizes[i] = booke206_tlb_size(env, i);
+params.tlb_ways[i] = booke206_tlb_ways(env, i);
+entries += params.tlb_sizes[i];
+}
+
+assert(entries == env-nb_tlb);
+assert(sizeof(struct kvm_book3e_206_tlb_entry) == sizeof(ppcmas_tlb_t));
+
+array_len = sizeof(ppcmas_tlb_t) * entries;
+env-tlb_dirty = true;
+
+cfg.array = (uintptr_t)env-tlb.tlbm;
+cfg.array_len = sizeof(ppcmas_tlb_t) * entries;
+cfg.params = (uintptr_t)params;
+cfg.mmu_type = KVM_MMU_FSL_BOOKE_NOHV;
+
+encap.cap = KVM_CAP_SW_TLB;
+encap.args[0] = (uintptr_t)cfg;
+
+ret = kvm_vcpu_ioctl(env, KVM_ENABLE_CAP, encap);
+if (ret 0) {
+fprintf(stderr, %s: couldn't enable KVM_CAP_SW_TLB: %s\n,
+__func__, strerror(-ret));
+return ret;
+}
+
+env-kvm_sw_tlb = true;
+return 0;
+}
+
int kvm_arch_init_vcpu(CPUState *cenv)
{
int ret;
@@ -116,6 +164,15 @@ int kvm_arch_init_vcpu(CPUState *cenv)
idle_timer = qemu_new_timer_ns(vm_clock, kvm_kick_env, cenv);
+/* Some targets support access to KVM's guest TLB. */
+switch (cenv-mmu_model) {
+case POWERPC_MMU_BOOKE206:
+ret = kvm_booke206_tlb_init(cenv);
+break;
+default:
+break;
+}
+
return ret;
}
@@ -123,6 +180,31 @@ void kvm_arch_reset_vcpu(CPUState *env)
{
}
+static void kvm_sw_tlb_put(CPUState *env)
+{
+struct kvm_dirty_tlb dirty_tlb;
+unsigned char *bitmap;
+int ret;
+
+if (!env-kvm_sw_tlb) {
+return;
+}
+
+bitmap = qemu_malloc((env-nb_tlb + 7) / 8);
+memset(bitmap, 0xFF, (env-nb_tlb + 7) / 8);
+
+dirty_tlb.bitmap = (uintptr_t)bitmap;
+dirty_tlb.num_dirty = env-nb_tlb;
+
+ret = kvm_vcpu_ioctl(env, KVM_DIRTY_TLB, dirty_tlb);
+if (ret) {
+fprintf(stderr, %s: KVM_DIRTY_TLB: %s\n,
+__func__, strerror(-ret));
+}
+
+qemu_free(bitmap);
+}
+
int kvm_arch_put_registers(CPUState *env, int level)
{
struct kvm_regs regs;
@@ -160,6 +242,11 @@ int kvm_arch_put_registers(CPUState *env, int level)
if (ret 0)
return ret;
+if (env-tlb_dirty) {
+kvm_sw_tlb_put(env);
+env-tlb_dirty = false;
+}
+
return ret;
}
--
1.7.6
[Qemu-devel] [PATCH v2 4/4] ppc: booke206: add info tlb support
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2 (was 3/3 in v1): no change
hmp-commands.hx |2 +-
monitor.c |5 ++-
target-ppc/cpu.h|2 +
target-ppc/helper.c | 88 +++
4 files changed, 94 insertions(+), 3 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0ccfb28..589c1ef 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1306,7 +1306,7 @@ show i8259 (PIC) state
@item info pci
show emulated PCI device info
@item info tlb
-show virtual to physical memory mappings (i386, SH4 and SPARC only)
+show virtual to physical memory mappings (i386, SH4, SPARC, and PPC only)
@item info mem
show the active virtual memory mappings (i386 only)
@item info jit
diff --git a/monitor.c b/monitor.c
index 1b8ba2c..a59aefd 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2442,7 +2442,7 @@ static void tlb_info(Monitor *mon)
#endif
-#if defined(TARGET_SPARC)
+#if defined(TARGET_SPARC) || defined(TARGET_PPC)
static void tlb_info(Monitor *mon)
{
CPUState *env1 = mon_get_cpu();
@@ -2935,7 +2935,8 @@ static const mon_cmd_t info_cmds[] = {
.user_print = do_pci_info_print,
.mhandler.info_new = do_pci_info,
},
-#if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC)
+#if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC) || \
+defined(TARGET_PPC)
{
.name = tlb,
.args_type = ,
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 06d78ca..dd5e021 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -2030,4 +2030,6 @@ static inline void cpu_pc_from_tb(CPUState *env,
TranslationBlock *tb)
env-nip = tb-pc;
}
+void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env);
+
#endif /* !defined (__CPU_PPC_H__) */
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index d9a3855..1c77ed7 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1466,6 +1466,94 @@ found_tlb:
return ret;
}
+static const char *book3e_tsize_to_str[32] = {
+1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K,
+1M, 2M, 4M, 8M, 16M, 32M, 64M, 128M, 256M, 512M,
+1G, 2G, 4G, 8G, 16G, 32G, 64G, 128G, 256G, 512G,
+1T, 2T
+};
+
+static void mmubooke206_dump_one_tlb(FILE *f, fprintf_function cpu_fprintf,
+ CPUState *env, int tlbn, int offset,
+ int tlbsize)
+{
+ppcmas_tlb_t *entry;
+int i;
+
+cpu_fprintf(f, \nTLB%d:\n, tlbn);
+cpu_fprintf(f, Effective Physical Size TID TS SRWX
URWX WIMGE U0123\n);
+
+entry = env-tlb.tlbm[offset];
+for (i = 0; i tlbsize; i++, entry++) {
+target_phys_addr_t ea, pa, size;
+int tsize;
+
+if (!(entry-mas1 MAS1_VALID)) {
+continue;
+}
+
+tsize = (entry-mas1 MAS1_TSIZE_MASK) MAS1_TSIZE_SHIFT;
+size = 1024ULL tsize;
+ea = entry-mas2 ~(size - 1);
+pa = entry-mas7_3 ~(size - 1);
+
+cpu_fprintf(f, 0x%016 PRIx64 0x%016 PRIx64 %4s %-5u %1u
S%c%c%c U%c%c%c %c%c%c%c%c U%c%c%c%c\n,
+(uint64_t)ea, (uint64_t)pa,
+book3e_tsize_to_str[tsize],
+(entry-mas1 MAS1_TID_MASK) MAS1_TID_SHIFT,
+(entry-mas1 MAS1_TS) MAS1_TS_SHIFT,
+entry-mas7_3 MAS3_SR ? 'R' : '-',
+entry-mas7_3 MAS3_SW ? 'W' : '-',
+entry-mas7_3 MAS3_SX ? 'X' : '-',
+entry-mas7_3 MAS3_UR ? 'R' : '-',
+entry-mas7_3 MAS3_UW ? 'W' : '-',
+entry-mas7_3 MAS3_UX ? 'X' : '-',
+entry-mas2 MAS2_W ? 'W' : '-',
+entry-mas2 MAS2_I ? 'I' : '-',
+entry-mas2 MAS2_M ? 'M' : '-',
+entry-mas2 MAS2_G ? 'G' : '-',
+entry-mas2 MAS2_E ? 'E' : '-',
+entry-mas7_3 MAS3_U0 ? '0' : '-',
+entry-mas7_3 MAS3_U1 ? '1' : '-',
+entry-mas7_3 MAS3_U2 ? '2' : '-',
+entry-mas7_3 MAS3_U3 ? '3' : '-');
+}
+}
+
+static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
+ CPUState *env)
+{
+int offset = 0;
+int i;
+
+if (kvm_enabled() !env-kvm_sw_tlb) {
+cpu_fprintf(f, Cannot access KVM TLB\n);
+return;
+}
+
+for (i = 0; i BOOKE206_MAX_TLBN; i++) {
+int size = booke206_tlb_size(env, i);
+
+if (size == 0) {
+continue;
+}
+
+mmubooke206_dump_one_tlb(f, cpu_fprintf, env, i, offset, size);
+offset += size;
+}
+}
+
+void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
+{
+switch (env-mmu_model) {
+case POWERPC_MMU_BOOKE206:
+mmubooke206_dump_mmu(f, cpu_fprintf, env);
+break;
+default:
+
[Qemu-devel] [PATCH v2 3/4] ppc: booke206: use MAV=2.0 TSIZE definition, fix 4G pages
This definition is backward compatible with MAV=1.0 as long as
the guest does not set reserved bits in MAS1/MAS4.
Also, fix the shift in booke206_tlb_to_page_size -- it's the base
that should be able to hold a 4G page size, not the shift count.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2 (was 2/3 in v1): no change
hw/ppce500_mpc8544ds.c |2 +-
target-ppc/cpu.h |4 ++--
target-ppc/helper.c|5 +++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/ppce500_mpc8544ds.c b/hw/ppce500_mpc8544ds.c
index 3626e26..1aed612 100644
--- a/hw/ppce500_mpc8544ds.c
+++ b/hw/ppce500_mpc8544ds.c
@@ -187,7 +187,7 @@ out:
/* Create -kernel TLB entries for BookE, linearly spanning 256MB. */
static inline target_phys_addr_t booke206_page_size_to_tlb(uint64_t size)
{
-return (ffs(size 10) - 1) 1;
+return ffs(size 10) - 1;
}
static void mmubooke_create_initial_mapping(CPUState *env,
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 0e38d4f..06d78ca 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -652,8 +652,8 @@ enum {
#define MAS0_ATSEL_TLB 0
#define MAS0_ATSEL_LRATMAS0_ATSEL
-#define MAS1_TSIZE_SHIFT 8
-#define MAS1_TSIZE_MASK(0xf MAS1_TSIZE_SHIFT)
+#define MAS1_TSIZE_SHIFT 7
+#define MAS1_TSIZE_MASK(0x1f MAS1_TSIZE_SHIFT)
#define MAS1_TS_SHIFT 12
#define MAS1_TS(1 MAS1_TS_SHIFT)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 789e6aa..d9a3855 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1293,7 +1293,7 @@ target_phys_addr_t booke206_tlb_to_page_size(CPUState
*env, ppcmas_tlb_t *tlb)
{
uint32_t tlbncfg;
int tlbn = booke206_tlbm_to_tlbn(env, tlb);
-target_phys_addr_t tlbm_size;
+int tlbm_size;
tlbncfg = env-spr[SPR_BOOKE_TLB0CFG + tlbn];
@@ -1301,9 +1301,10 @@ target_phys_addr_t booke206_tlb_to_page_size(CPUState
*env, ppcmas_tlb_t *tlb)
tlbm_size = (tlb-mas1 MAS1_TSIZE_MASK) MAS1_TSIZE_SHIFT;
} else {
tlbm_size = (tlbncfg TLBnCFG_MINSIZE) TLBnCFG_MINSIZE_SHIFT;
+tlbm_size = 1;
}
-return (1 (tlbm_size 1)) 10;
+return 1024ULL tlbm_size;
}
/* TLB check function for MAS based SoftTLBs */
--
1.7.6
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? He is! xD There is no problem for me, he can do... Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. You know, nights are not long enough... We only lack the 68k cpu (oh! your patches!!!) and the glue :p this part is not working well as well ... gcc cannot compile linux kernel, some demos fail in gtk-demo, ... Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( I believe only in Santa Claus, and it's not Christmas. (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!) Regards, Laurent
Re: [Qemu-devel] [PATCH v2 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode
On 2011-08-17 16:48, Avi Kivity wrote: On 08/17/2011 04:38 PM, Avi Kivity wrote: The mmio code has s-plane_updated |= mask; /* only used to detect font change */ aren't we losing it? we could easily recover it via dirty logging. Yes, I forgot to forward-port plane_updated = 0xf from v1 of the patch. We can't really recover it. I don't see yet why we should not if we simply enforce a full update. Can you elaborate? So I think we need to restrict the optimization to graphic mode. Is grub using text mode or graphic mode? If it's using text mode, it may be faster to compare the font plane to a snapshot from the last redraw than to take an exit. I wasn't optimizing for text mode here, it's just a side effect if it happens to benefit from it as well. I could exclude it, but only if really needed. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] block/curl: Handle failed reads gracefully.
Am 15.08.2011 11:00, schrieb Nicholas Thomas: Current behaviour if a read fails is for the acb to not get finished. This causes an infinite loop in bdrv_read_em (block.c). The read failure never gets reported to the guest and if the error condition clears, the process never recovers. With this patch, when curl reports a failure we finish the acb as a failure. This results in the guest receiving an I/O error (rather than the read hanging indefinitely) and if the error condition subsequently clears, retries work as expected. The simplest test is to put an ISO on a web server you have control over and open it with qemu-io. Then move the ISO out of the way and attempt to read some data - you should see behaviour matching the above. Signed-off-by: Nick Thomas n...@bytemark.co.uk Thanks, applied to the block branch. Kevin
[Qemu-devel] ahmed
Je suis le fils de l'ancien ministre de la Guinée (Mariame Sy Diallo) mais je vis actuellement en Angleterre, j'ai trouvé votre adresse à la chambre de commerce ici à Londres, j'ai besoin de votre aide pour investir au Maroc ou Algérie ou en Tunisie. Si vous êtes intéressé à ma demandes'il vous plaît contactez-moi sur mon adresse e-mail (ahmeddiall...@gmail.com) ou sur mon numéro, (+447031869448). Merci de votre bonne compréhension Ahmed. Pour plus de détails. Je veux en savoir plus sur vous Votre nom ... Votre ville actuelle... Votre profession ... ... ... ... .. V
[Qemu-devel] [PATCH, braille] Add dots keypresses support to the baum braille device
Add dots keypresses support to the baum braille device.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/hw/baum.c b/hw/baum.c
index 21326ae..131348c 100644
--- a/hw/baum.c
+++ b/hw/baum.c
@@ -1,7 +1,7 @@
/*
* QEMU Baum Braille Device
*
- * Copyright (c) 2008, 2011 Samuel Thibault
+ * Copyright (c) 2008, 2010-2011 Samuel Thibault
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to
deal
@@ -101,8 +101,11 @@ typedef struct {
} BaumDriverState;
/* Let's assume NABCC by default */
-static const uint8_t nabcc_translation[256] = {
-[0] = ' ',
+enum way {
+DOTS2ASCII,
+ASCII2DOTS
+};
+static const uint8_t nabcc_translation[2][256] = {
#ifndef BRLAPI_DOTS
#define BRLAPI_DOTS(d1,d2,d3,d4,d5,d6,d7,d8) \
((d1?BRLAPI_DOT1:0)|\
@@ -114,105 +117,109 @@ static const uint8_t nabcc_translation[256] = {
(d7?BRLAPI_DOT7:0)|\
(d8?BRLAPI_DOT8:0))
#endif
-[BRLAPI_DOTS(1,0,0,0,0,0,0,0)] = 'a',
-[BRLAPI_DOTS(1,1,0,0,0,0,0,0)] = 'b',
-[BRLAPI_DOTS(1,0,0,1,0,0,0,0)] = 'c',
-[BRLAPI_DOTS(1,0,0,1,1,0,0,0)] = 'd',
-[BRLAPI_DOTS(1,0,0,0,1,0,0,0)] = 'e',
-[BRLAPI_DOTS(1,1,0,1,0,0,0,0)] = 'f',
-[BRLAPI_DOTS(1,1,0,1,1,0,0,0)] = 'g',
-[BRLAPI_DOTS(1,1,0,0,1,0,0,0)] = 'h',
-[BRLAPI_DOTS(0,1,0,1,0,0,0,0)] = 'i',
-[BRLAPI_DOTS(0,1,0,1,1,0,0,0)] = 'j',
-[BRLAPI_DOTS(1,0,1,0,0,0,0,0)] = 'k',
-[BRLAPI_DOTS(1,1,1,0,0,0,0,0)] = 'l',
-[BRLAPI_DOTS(1,0,1,1,0,0,0,0)] = 'm',
-[BRLAPI_DOTS(1,0,1,1,1,0,0,0)] = 'n',
-[BRLAPI_DOTS(1,0,1,0,1,0,0,0)] = 'o',
-[BRLAPI_DOTS(1,1,1,1,0,0,0,0)] = 'p',
-[BRLAPI_DOTS(1,1,1,1,1,0,0,0)] = 'q',
-[BRLAPI_DOTS(1,1,1,0,1,0,0,0)] = 'r',
-[BRLAPI_DOTS(0,1,1,1,0,0,0,0)] = 's',
-[BRLAPI_DOTS(0,1,1,1,1,0,0,0)] = 't',
-[BRLAPI_DOTS(1,0,1,0,0,1,0,0)] = 'u',
-[BRLAPI_DOTS(1,1,1,0,0,1,0,0)] = 'v',
-[BRLAPI_DOTS(0,1,0,1,1,1,0,0)] = 'w',
-[BRLAPI_DOTS(1,0,1,1,0,1,0,0)] = 'x',
-[BRLAPI_DOTS(1,0,1,1,1,1,0,0)] = 'y',
-[BRLAPI_DOTS(1,0,1,0,1,1,0,0)] = 'z',
-
-[BRLAPI_DOTS(1,0,0,0,0,0,1,0)] = 'A',
-[BRLAPI_DOTS(1,1,0,0,0,0,1,0)] = 'B',
-[BRLAPI_DOTS(1,0,0,1,0,0,1,0)] = 'C',
-[BRLAPI_DOTS(1,0,0,1,1,0,1,0)] = 'D',
-[BRLAPI_DOTS(1,0,0,0,1,0,1,0)] = 'E',
-[BRLAPI_DOTS(1,1,0,1,0,0,1,0)] = 'F',
-[BRLAPI_DOTS(1,1,0,1,1,0,1,0)] = 'G',
-[BRLAPI_DOTS(1,1,0,0,1,0,1,0)] = 'H',
-[BRLAPI_DOTS(0,1,0,1,0,0,1,0)] = 'I',
-[BRLAPI_DOTS(0,1,0,1,1,0,1,0)] = 'J',
-[BRLAPI_DOTS(1,0,1,0,0,0,1,0)] = 'K',
-[BRLAPI_DOTS(1,1,1,0,0,0,1,0)] = 'L',
-[BRLAPI_DOTS(1,0,1,1,0,0,1,0)] = 'M',
-[BRLAPI_DOTS(1,0,1,1,1,0,1,0)] = 'N',
-[BRLAPI_DOTS(1,0,1,0,1,0,1,0)] = 'O',
-[BRLAPI_DOTS(1,1,1,1,0,0,1,0)] = 'P',
-[BRLAPI_DOTS(1,1,1,1,1,0,1,0)] = 'Q',
-[BRLAPI_DOTS(1,1,1,0,1,0,1,0)] = 'R',
-[BRLAPI_DOTS(0,1,1,1,0,0,1,0)] = 'S',
-[BRLAPI_DOTS(0,1,1,1,1,0,1,0)] = 'T',
-[BRLAPI_DOTS(1,0,1,0,0,1,1,0)] = 'U',
-[BRLAPI_DOTS(1,1,1,0,0,1,1,0)] = 'V',
-[BRLAPI_DOTS(0,1,0,1,1,1,1,0)] = 'W',
-[BRLAPI_DOTS(1,0,1,1,0,1,1,0)] = 'X',
-[BRLAPI_DOTS(1,0,1,1,1,1,1,0)] = 'Y',
-[BRLAPI_DOTS(1,0,1,0,1,1,1,0)] = 'Z',
-
-[BRLAPI_DOTS(0,0,1,0,1,1,0,0)] = '0',
-[BRLAPI_DOTS(0,1,0,0,0,0,0,0)] = '1',
-[BRLAPI_DOTS(0,1,1,0,0,0,0,0)] = '2',
-[BRLAPI_DOTS(0,1,0,0,1,0,0,0)] = '3',
-[BRLAPI_DOTS(0,1,0,0,1,1,0,0)] = '4',
-[BRLAPI_DOTS(0,1,0,0,0,1,0,0)] = '5',
-[BRLAPI_DOTS(0,1,1,0,1,0,0,0)] = '6',
-[BRLAPI_DOTS(0,1,1,0,1,1,0,0)] = '7',
-[BRLAPI_DOTS(0,1,1,0,0,1,0,0)] = '8',
-[BRLAPI_DOTS(0,0,1,0,1,0,0,0)] = '9',
-
-[BRLAPI_DOTS(0,0,0,1,0,1,0,0)] = '.',
-[BRLAPI_DOTS(0,0,1,1,0,1,0,0)] = '+',
-[BRLAPI_DOTS(0,0,1,0,0,1,0,0)] = '-',
-[BRLAPI_DOTS(1,0,0,0,0,1,0,0)] = '*',
-[BRLAPI_DOTS(0,0,1,1,0,0,0,0)] = '/',
-[BRLAPI_DOTS(1,1,1,0,1,1,0,0)] = '(',
-[BRLAPI_DOTS(0,1,1,1,1,1,0,0)] = ')',
-
-[BRLAPI_DOTS(1,1,1,1,0,1,0,0)] = '',
-[BRLAPI_DOTS(0,0,1,1,1,1,0,0)] = '#',
-
-[BRLAPI_DOTS(0,0,0,0,0,1,0,0)] = ',',
-[BRLAPI_DOTS(0,0,0,0,1,1,0,0)] = ';',
-[BRLAPI_DOTS(1,0,0,0,1,1,0,0)] = ':',
-[BRLAPI_DOTS(0,1,1,1,0,1,0,0)] = '!',
-[BRLAPI_DOTS(1,0,0,1,1,1,0,0)] = '?',
-[BRLAPI_DOTS(0,0,0,0,1,0,0,0)] = '',
-[BRLAPI_DOTS(0,0,1,0,0,0,0,0)] ='\'',
-[BRLAPI_DOTS(0,0,0,1,0,0,0,0)] = '`',
-[BRLAPI_DOTS(0,0,0,1,1,0,1,0)] = '^',
-[BRLAPI_DOTS(0,0,0,1,1,0,0,0)] = '~',
-[BRLAPI_DOTS(0,1,0,1,0,1,1,0)] = '[',
-[BRLAPI_DOTS(1,1,0,1,1,1,1,0)] = ']',
-[BRLAPI_DOTS(0,1,0,1,0,1,0,0)] = '{',
-[BRLAPI_DOTS(1,1,0,1,1,1,0,0)] = '}',
-[BRLAPI_DOTS(1,1,1,1,1,1,0,0)] = '=',
-[BRLAPI_DOTS(1,1,0,0,0,1,0,0)] = '',
-[BRLAPI_DOTS(0,0,1,1,1,0,0,0)] = '',
-[BRLAPI_DOTS(1,1,0,1,0,1,0,0)] = '$',
-[BRLAPI_DOTS(1,0,0,1,0,1,0,0)] = '%',
-[BRLAPI_DOTS(0,0,0,1,0,0,1,0)] = '@',
-[BRLAPI_DOTS(1,1,0,0,1,1,0,0)] = '|',
-
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Hi, El 18/08/2011, a las 21:51, Laurent Vivier escribió: Le jeudi 18 août 2011 à 21:13 +0100, Natalia Portillo a écrit : Hi Laurent, El 18/08/2011, a las 20:57, Laurent Vivier escribió: Le jeudi 18 août 2011 à 20:42 +0100, Natalia Portillo a écrit : Hi Laurent, Hi Natalia, El 18/08/2011, a las 15:02, Laurent Vivier escribió: Le 18 août 2011 à 13:12, François Revol re...@free.fr a écrit : Le -10/01/-28163 20:59, Laurent Vivier a écrit : Le mercredi 17 août 2011 à 17:35 -0500, Anthony Liguori a écrit : On 08/17/2011 03:46 PM, Bryce Lanham wrote: These patches greatly expand Motorola 68k emulation within qemu, and are what I used as a basis for my Google Summer of Code project to add NeXT hardware support to QEMU. Please don't crap flood the list with a series of 100 patches. Split things into logical chunks such that a series can be reasonably reviewed and applied. And I'm not sure this series of patches is ready for inclusion in qemu mainline as it should break existing m68k emulation... Bryce, you should only post your patches, refering to the repository on which they apply, i.e. git://gitorious.org/qemu-m68k/qemu-m68k.git , master branch. Btw, are you planning on merging it back someday? Yes... when it will work correctly. I have at least, to rework 680x0 FPU part (80bit fpu) to not break the existing one (64bit fpu). I have to check modified instructions don't break existing m68k emulation. Maybe Bryce can help you I don't know if he is courageous enough to review and push 111 patches ;-) He worked on emulating an abandoned, strange, difficult to get, and undocumented hardware, using your 111 patches, and finished it before the wholy more experienced MESS team. The next-cube emulation is really working ? Yes, it is, absolutely. He is! xD There is no problem for me, he can do... Currently, I'm trying to port some parts of BasiliskII into Qemu to be able to boot MacOS 7.6. Why are you planning to port a hack instead of making a full machine emulation? Because I'm lazy and dumb: the work is already done, I like cut'n'paste. Yeah, you said it! The work is already done, we have all the hardware emulation that Basilisk substitutes for hacks. I'm not sure of that... no MMU emulation, no Nubus, no ethernet card, no video card, no SWIM, no SCSI, ... useless with a patched ROM. Macs do not have videocards :p, only the Mac II and we're not forced to emulate that one. SWIM is a piece of cake that can be even implemented without ICs, just some logical arrays. NuBus is not required for almost anything, only the video card uses it, and it's present only on the Mac II, a stub will suffice to make Toolbox be happy. Most m68k didn't include a network card, third party ones are stock chips (probably almost all are NE2000, 3COM and PCNET), and Apple integrated ones are also stock, easy to do :p The MMU is your part I won't discuss on it. But porting BasiliskII will not make qemu have an m68k-system, but a macos7-wrapper. And that's the problem with Basilisk, that's why you cannot partition a disk, try MachTen, don't even think on A/UX. If you insist, please name it basilisk2 and let Bryce (he wants to in the future) do the real machines (-M quadra, -M centris, -M IIcx) You know, nights are not long enough... Move to North Pole, I've heard nights are six month long there ^^ We only lack the 68k cpu (oh! your patches!!!) and the glue :p this part is not working well as well ... gcc cannot compile linux kernel, some demos fail in gtk-demo, ... I know it's not perfect, but right now, it's better than nothing. There is no 68k cpu emulation complete afaik, I discussed with Ray Arachelian a lot on that when he was working on LisaEm. However emulators are live, Aranym, UAE, LisaEm, BasiliskII. qemu-m68k is quite complete to go live (when it does not break mcoldfire) right now. Bugs are easy to be corrected by more people when they are in main than in a developer's own clone. Leave your little kid go wild, it's old and big enough :p Please don't port Basilisk on top of TCG, I beg to you in the name of some god of your own choice :( I believe only in Santa Claus, and it's not Christmas. (1000 Mb floppies patching .sony instead of implementing SCSI and SWIM, no ethernet controller but a working TCP/IP, oh hell, it's not a Mac, it's a Match!) Regards, Laurent
Re: [Qemu-devel] [PATCH, braille] Add dots keypresses support to the baum braille device
Oops, sorry, the previous patch had a debugging leftover, here it is
again.
Add dots keypresses support to the baum braille device.
Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org
diff --git a/hw/baum.c b/hw/baum.c
index 21326ae..0b29498 100644
--- a/hw/baum.c
+++ b/hw/baum.c
@@ -1,7 +1,7 @@
/*
* QEMU Baum Braille Device
*
- * Copyright (c) 2008, 2011 Samuel Thibault
+ * Copyright (c) 2008, 2010-2011 Samuel Thibault
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to
deal
@@ -101,8 +101,11 @@ typedef struct {
} BaumDriverState;
/* Let's assume NABCC by default */
-static const uint8_t nabcc_translation[256] = {
-[0] = ' ',
+enum way {
+DOTS2ASCII,
+ASCII2DOTS
+};
+static const uint8_t nabcc_translation[2][256] = {
#ifndef BRLAPI_DOTS
#define BRLAPI_DOTS(d1,d2,d3,d4,d5,d6,d7,d8) \
((d1?BRLAPI_DOT1:0)|\
@@ -114,105 +117,109 @@ static const uint8_t nabcc_translation[256] = {
(d7?BRLAPI_DOT7:0)|\
(d8?BRLAPI_DOT8:0))
#endif
-[BRLAPI_DOTS(1,0,0,0,0,0,0,0)] = 'a',
-[BRLAPI_DOTS(1,1,0,0,0,0,0,0)] = 'b',
-[BRLAPI_DOTS(1,0,0,1,0,0,0,0)] = 'c',
-[BRLAPI_DOTS(1,0,0,1,1,0,0,0)] = 'd',
-[BRLAPI_DOTS(1,0,0,0,1,0,0,0)] = 'e',
-[BRLAPI_DOTS(1,1,0,1,0,0,0,0)] = 'f',
-[BRLAPI_DOTS(1,1,0,1,1,0,0,0)] = 'g',
-[BRLAPI_DOTS(1,1,0,0,1,0,0,0)] = 'h',
-[BRLAPI_DOTS(0,1,0,1,0,0,0,0)] = 'i',
-[BRLAPI_DOTS(0,1,0,1,1,0,0,0)] = 'j',
-[BRLAPI_DOTS(1,0,1,0,0,0,0,0)] = 'k',
-[BRLAPI_DOTS(1,1,1,0,0,0,0,0)] = 'l',
-[BRLAPI_DOTS(1,0,1,1,0,0,0,0)] = 'm',
-[BRLAPI_DOTS(1,0,1,1,1,0,0,0)] = 'n',
-[BRLAPI_DOTS(1,0,1,0,1,0,0,0)] = 'o',
-[BRLAPI_DOTS(1,1,1,1,0,0,0,0)] = 'p',
-[BRLAPI_DOTS(1,1,1,1,1,0,0,0)] = 'q',
-[BRLAPI_DOTS(1,1,1,0,1,0,0,0)] = 'r',
-[BRLAPI_DOTS(0,1,1,1,0,0,0,0)] = 's',
-[BRLAPI_DOTS(0,1,1,1,1,0,0,0)] = 't',
-[BRLAPI_DOTS(1,0,1,0,0,1,0,0)] = 'u',
-[BRLAPI_DOTS(1,1,1,0,0,1,0,0)] = 'v',
-[BRLAPI_DOTS(0,1,0,1,1,1,0,0)] = 'w',
-[BRLAPI_DOTS(1,0,1,1,0,1,0,0)] = 'x',
-[BRLAPI_DOTS(1,0,1,1,1,1,0,0)] = 'y',
-[BRLAPI_DOTS(1,0,1,0,1,1,0,0)] = 'z',
-
-[BRLAPI_DOTS(1,0,0,0,0,0,1,0)] = 'A',
-[BRLAPI_DOTS(1,1,0,0,0,0,1,0)] = 'B',
-[BRLAPI_DOTS(1,0,0,1,0,0,1,0)] = 'C',
-[BRLAPI_DOTS(1,0,0,1,1,0,1,0)] = 'D',
-[BRLAPI_DOTS(1,0,0,0,1,0,1,0)] = 'E',
-[BRLAPI_DOTS(1,1,0,1,0,0,1,0)] = 'F',
-[BRLAPI_DOTS(1,1,0,1,1,0,1,0)] = 'G',
-[BRLAPI_DOTS(1,1,0,0,1,0,1,0)] = 'H',
-[BRLAPI_DOTS(0,1,0,1,0,0,1,0)] = 'I',
-[BRLAPI_DOTS(0,1,0,1,1,0,1,0)] = 'J',
-[BRLAPI_DOTS(1,0,1,0,0,0,1,0)] = 'K',
-[BRLAPI_DOTS(1,1,1,0,0,0,1,0)] = 'L',
-[BRLAPI_DOTS(1,0,1,1,0,0,1,0)] = 'M',
-[BRLAPI_DOTS(1,0,1,1,1,0,1,0)] = 'N',
-[BRLAPI_DOTS(1,0,1,0,1,0,1,0)] = 'O',
-[BRLAPI_DOTS(1,1,1,1,0,0,1,0)] = 'P',
-[BRLAPI_DOTS(1,1,1,1,1,0,1,0)] = 'Q',
-[BRLAPI_DOTS(1,1,1,0,1,0,1,0)] = 'R',
-[BRLAPI_DOTS(0,1,1,1,0,0,1,0)] = 'S',
-[BRLAPI_DOTS(0,1,1,1,1,0,1,0)] = 'T',
-[BRLAPI_DOTS(1,0,1,0,0,1,1,0)] = 'U',
-[BRLAPI_DOTS(1,1,1,0,0,1,1,0)] = 'V',
-[BRLAPI_DOTS(0,1,0,1,1,1,1,0)] = 'W',
-[BRLAPI_DOTS(1,0,1,1,0,1,1,0)] = 'X',
-[BRLAPI_DOTS(1,0,1,1,1,1,1,0)] = 'Y',
-[BRLAPI_DOTS(1,0,1,0,1,1,1,0)] = 'Z',
-
-[BRLAPI_DOTS(0,0,1,0,1,1,0,0)] = '0',
-[BRLAPI_DOTS(0,1,0,0,0,0,0,0)] = '1',
-[BRLAPI_DOTS(0,1,1,0,0,0,0,0)] = '2',
-[BRLAPI_DOTS(0,1,0,0,1,0,0,0)] = '3',
-[BRLAPI_DOTS(0,1,0,0,1,1,0,0)] = '4',
-[BRLAPI_DOTS(0,1,0,0,0,1,0,0)] = '5',
-[BRLAPI_DOTS(0,1,1,0,1,0,0,0)] = '6',
-[BRLAPI_DOTS(0,1,1,0,1,1,0,0)] = '7',
-[BRLAPI_DOTS(0,1,1,0,0,1,0,0)] = '8',
-[BRLAPI_DOTS(0,0,1,0,1,0,0,0)] = '9',
-
-[BRLAPI_DOTS(0,0,0,1,0,1,0,0)] = '.',
-[BRLAPI_DOTS(0,0,1,1,0,1,0,0)] = '+',
-[BRLAPI_DOTS(0,0,1,0,0,1,0,0)] = '-',
-[BRLAPI_DOTS(1,0,0,0,0,1,0,0)] = '*',
-[BRLAPI_DOTS(0,0,1,1,0,0,0,0)] = '/',
-[BRLAPI_DOTS(1,1,1,0,1,1,0,0)] = '(',
-[BRLAPI_DOTS(0,1,1,1,1,1,0,0)] = ')',
-
-[BRLAPI_DOTS(1,1,1,1,0,1,0,0)] = '',
-[BRLAPI_DOTS(0,0,1,1,1,1,0,0)] = '#',
-
-[BRLAPI_DOTS(0,0,0,0,0,1,0,0)] = ',',
-[BRLAPI_DOTS(0,0,0,0,1,1,0,0)] = ';',
-[BRLAPI_DOTS(1,0,0,0,1,1,0,0)] = ':',
-[BRLAPI_DOTS(0,1,1,1,0,1,0,0)] = '!',
-[BRLAPI_DOTS(1,0,0,1,1,1,0,0)] = '?',
-[BRLAPI_DOTS(0,0,0,0,1,0,0,0)] = '',
-[BRLAPI_DOTS(0,0,1,0,0,0,0,0)] ='\'',
-[BRLAPI_DOTS(0,0,0,1,0,0,0,0)] = '`',
-[BRLAPI_DOTS(0,0,0,1,1,0,1,0)] = '^',
-[BRLAPI_DOTS(0,0,0,1,1,0,0,0)] = '~',
-[BRLAPI_DOTS(0,1,0,1,0,1,1,0)] = '[',
-[BRLAPI_DOTS(1,1,0,1,1,1,1,0)] = ']',
-[BRLAPI_DOTS(0,1,0,1,0,1,0,0)] = '{',
-[BRLAPI_DOTS(1,1,0,1,1,1,0,0)] = '}',
-[BRLAPI_DOTS(1,1,1,1,1,1,0,0)] = '=',
-[BRLAPI_DOTS(1,1,0,0,0,1,0,0)] = '',
-[BRLAPI_DOTS(0,0,1,1,1,0,0,0)] = '',
-[BRLAPI_DOTS(1,1,0,1,0,1,0,0)] = '$',
-[BRLAPI_DOTS(1,0,0,1,0,1,0,0)] = '%',
-
Re: [Qemu-devel] [PATCH] Fix gcc-4.6 compiler error
On Thu, Aug 18, 2011 at 12:28 PM, Peter Maydell peter.mayd...@linaro.org wrote: On 18 August 2011 05:16, Zhi Yong Wu zwu.ker...@gmail.com wrote: I have also met this problem on fedora 15 today. Currently i disable werror option to build successfully. How to completely this problem regardless of gcc=4.6? Hmm, this should have been fixed by commit 257a73755. Can you tell us which git revision you are trying to build and quote the complete error message from gcc, please? Sorry, my branch is a bit old. After rebasing it to latest version, the fix has checked in and this issue has been resolved. thanks. thanks -- PMM -- Regards, Zhi Yong Wu
Re: [Qemu-devel] Multi-threaded user program support?
More generally and not x86-specific, there are problems with the multithreaded user-mode support which I suspect exist because nobody has ever sat down and worked out a coherent design for it, including what might need to be thread-local and what locking is required. So the result is that it mostly works but if you You mean some QEMU data structures need to be thread-local or lock protected in order to emulate guest multi-threaded program correctly? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] Multi-threaded user program support?
On 19 August 2011 03:59, 陳韋任 che...@iis.sinica.edu.tw wrote: More generally and not x86-specific, there are problems with the multithreaded user-mode support which I suspect exist because nobody has ever sat down and worked out a coherent design for it, including what might need to be thread-local and what locking is required. So the result is that it mostly works but if you You mean some QEMU data structures need to be thread-local or lock protected in order to emulate guest multi-threaded program correctly? Approximately, yes (the third option being redesign the data structure so it can be sensibly protected). See https://bugs.launchpad.net/qemu/+bug/668799 for discussion of one example. None of this is impossibly difficult; it just requires that somebody sits down and actually works through the problems and fixes them. -- PMM
Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On Thu, Aug 18, 2011 at 6:48 PM, Avi Kivity a...@redhat.com wrote: This makes the tracing infrastructure available to users of g_new(). Signed-off-by: Avi Kivity a...@redhat.com --- qemu-common.h | 1 + qemu-malloc.c | 15 +++ vl.c | 1 + 3 files changed, 17 insertions(+), 0 deletions(-) Seems useful :) Stefan
Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On 18 August 2011 18:48, Avi Kivity a...@redhat.com wrote:
+static GMemVTable gmemvtable = {
+ .malloc = qemu_malloc,
+ .realloc = qemu_realloc,
+ .free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+ g_mem_set_vtable(gmemvtable);
+}
Does this mean you can now safely allocate with g_malloc
and free with qemu_free, or is mixing the two APIs like that
still a no-no ?
(I'm thinking about a situation where you might use a glib utility
function that returned g_malloc'd memory and want to pass that back
to your caller without having to either copy to qemu_malloc'd memory
or require your caller to care about the distinction.)
-- PMM
Re: [Qemu-devel] [PATCH] pci: add standard bridge device
At 08/18/2011 11:15 PM, Avi Kivity Write:
On 08/17/2011 08:22 PM, Wen Congyang wrote:
At 08/17/2011 04:37 PM, Wen Congyang Write:
At 07/04/2011 05:43 PM, Michael S. Tsirkin Write:
This adds support for a standard pci to pci bridge,
enabling support for more than 32 PCI devices in the system.
To use, specify the device id as a 'bus' option.
Example:
-device pci-bridge,id=bridge1 \
-netdev user,id=u \
-device ne2k_pci,id=net2,bus=bridge1,netdev=u
TODO: device hotplug support.
I try this patch, and found that when I use pci bridge, qemu will
core dump.
Here is my command line:
/usr/local2/bin/qemu-system-x86_64 -M pc-0.14 -enable-kvm -m 512
-name vm1 -drive
file=/var/lib/libvirt/images/vm1.img,if=none,id=drive-ide0-0-0,format=qcow2,cache=writethrough
-device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -vnc
0.0.0.0:1 -device pci-bridge,id=bridge1,bus=pci.0,addr=0x08.0x0
-netdev user,id=u -device ne2k_pci,id=net2,bus=bridge1,netdev=u
Here is the backtrace:
Core was generated by `/usr/local2/bin/qemu-system-x86_64 -M
pc-0.14 -enable-kvm -m 512 -name vm1 -dri'.
Program terminated with signal 11, Segmentation fault.
#0 0x00438e34 in memory_region_add_subregion_common
(mr=0x0, offset=49152, subregion=0x1de5d58) at
/home/wency/source/qemu/memory.c:1152
1152QTAILQ_FOREACH(other,mr-subregions, subregions_link) {
Missing separate debuginfos, use: debuginfo-install
SDL-1.2.14-2.el6.x86_64 celt051-0.5.1.3-0.el6.x86_64
cyrus-sasl-gssapi-2.1.23-8.el6.x86_64
cyrus-sasl-lib-2.1.23-8.el6.x86_64 cyrus-sasl-md5-2.1.23-8.el6.x86_64
cyrus-sasl-plain-2.1.23-8.el6.x86_64 db4-4.7.25-16.el6.x86_64
glib2-2.22.5-6.el6.x86_64 glibc-2.12-1.25.el6.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6.x86_64
libX11-1.3-2.el6.x86_64 libXau-1.0.5-1.el6.x86_64
libaio-0.3.107-10.el6.x86_64 libattr-2.4.44-4.el6.x86_64
libcom_err-1.41.12-7.el6.x86_64 libcurl-7.19.7-26.el6.x86_64
libgcrypt-1.4.5-5.el6.x86_64 libgpg-error-1.7-3.el6.x86_64
libidn-1.18-2.el6.x86_64 libjpeg-6b-46.el6.x86_64
libpng-1.2.44-1.el6.x86_64 libselinux-2.0.94-5.el6.x86_64
libssh2-1.2.2-7.el6.x86_64 libtasn1-2.3-3.el6.x86_64
libuuid-2.17.2-12.el6.x86_64 libxcb-1.5-1.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 nspr-4.8.7-1.el6.x86_64
nss-3.12.9-9.el6.x86_64 nss-softokn-freebl-3.12.9-3.el6.x86_64
nss-util-3.12.9-1.el6.x86_64 openld
ap
-2.4.23-15.el6.x86_64 openssl-1.0.0-10.el6.x86_64
pixman-0.18.4-1.el6_0.1.x86_64 spice-server-0.8.0-1.el6.x86_64
zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x00438e34 in memory_region_add_subregion_common
(mr=0x0, offset=49152, subregion=0x1de5d58) at
/home/wency/source/qemu/memory.c:1152
#1 0x00439090 in memory_region_add_subregion_overlap
(mr=0x0, offset=49152, subregion=0x1de5d58, priority=1) at
/home/wency/source/qemu/memory.c:1194
#2 0x005c55fe in pci_update_mappings (d=0x1de5900) at
/home/wency/source/qemu/hw/pci.c:1063
#3 0x005c5982 in pci_default_write_config (d=0x1de5900,
addr=4, val=0, l=2) at /home/wency/source/qemu/hw/pci.c:1121
#4 0x005cbfbf in pci_host_config_write_common
(pci_dev=0x1de5900, addr=4, limit=256, val=1, len=2) at
/home/wency/source/qemu/hw/pci_host.c:54
#5 0x005cc0d1 in pci_data_write (s=0x1da2b90,
addr=2147549188, val=1, len=2) at
/home/wency/source/qemu/hw/pci_host.c:75
#6 0x005cc2b1 in pci_host_data_write (handler=0x1da2b60,
addr=3324, val=1, len=2) at /home/wency/source/qemu/hw/pci_host.c:125
#7 0x0042c884 in ioport_simple_writew (opaque=0x1da2b60,
addr=3324, value=1) at /home/wency/source/qemu/rwhandler.c:50
#8 0x00499e85 in ioport_write (index=1, address=3324,
data=1) at ioport.c:81
#9 0x0049a8e1 in cpu_outw (addr=3324, val=1) at ioport.c:280
#10 0x00433c5d in kvm_handle_io (port=3324,
data=0x7f0b30f86000, direction=1, size=2, count=1) at
/home/wency/source/qemu/kvm-all.c:837
#11 0x004341c8 in kvm_cpu_exec (env=0x1b7fc70) at
/home/wency/source/qemu/kvm-all.c:976
#12 0x0040da99 in cpu_exec_all () at
/home/wency/source/qemu/cpus.c:1102
#13 0x005b60c4 in main_loop () at
/home/wency/source/qemu/vl.c:1392
#14 0x005baa49 in main (argc=20, argv=0x7a6b5a38,
envp=0x7a6b5ae0) at /home/wency/source/qemu/vl.c:3356
If I do not attach any device on bus bridge1, qemu can work nice.
Thanks
Wen Congyang
The following patch can fix this problem, but I'm not sure whether it
is right.
It's correct but insufficient, the filtering code (pci_bridge_filter)
needs to be updated to use the memory API.
I read the function pci_bridge_filter(), and the function only read
PCI bridge's config space(command, base and limit). If base limit,
it will set addr to PCI_BAR_UNMAPPED.
I do not find anything that needs to updated to use the memory API.
I add a scsi
