from:"ralf"

Leading spaces mustn't be stripped! The commandline could look like:
qemu -kernel kern -initrd "1.mod arg=foo arg2=bar, 2.mod arg=asdf"
The problem is, that the string
"1.mod arg=foo arg2=bar, 2.mod arg=asdf"
is divided at the ','. So we have two string
"1.mod arg=foo arg2=bar" and
" 2.mod arg=asdf"
 ^ This space causes the error "Failed to get image size"
So just the spaces at the beginning of the file have to be stripped.
Spaces at the end could be important for the commandline. E.g.
-initrd "1.mod arg=argwithmanyspaces, 2.mod"

--
Ralf

> If we want to do this, shouldn't it be done before adding to the
> multiboot command-line?  Otherwise the multiboot image also has to strip
> leading spaces.
>
> Stefan
>

Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading

On 07.04.2011 um 10:38, Alexander Graf wrote:
> 
> Also, I just realized that you did miss another small part that needs change. 
> A few lines above, there is code to interpret the modules right before that 
> as well:
> 
>if (initrd_filename) {
>const char *r = initrd_filename;
>mbs.mb_buf_size += strlen(r) + 1;
>mbs.mb_mods_avail = 1;
>while ((r = strchr(r, ','))) {
>   mbs.mb_mods_avail++;
>   r++;
>}
>mbs.mb_buf_size += MB_MOD_SIZE * mbs.mb_mods_avail;
>}
> 
> This code would need some change as well, as now the mb_buf_size field is 
> incorrect. It doesn't really hurt, but is bad style to not use the exact 
> amount of memory we need to.

You're right, I didn't look at this section. But now i had a deeper look into 
the code, and I noticed the the mb_buf size seems to be incorrect anyway.

Look at this line:

mbs.mb_buf_size += strlen(r) + 1;

If I start qemu with the option -initrd "mod1 arg=bla, mod2 arg=foo, mod3 
arg=bar", then r contains
"mod1 arg=bla, mod2 arg=foo, mod3 arg=bar", so the commas and spaces after the 
comma are counted for the size of the multiboot command line.
Yes, this doesn't really hurt, but it's nevertheless not the exact amount of 
memory. I'll try to fix it.

--
Ralf

Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading

Hello again,

there's another problem with parsing the initrd string:

If you want to start qemu with ... -initrd "mod1 arg=foo,bar , mod2 
arg=bar,foo" it won't work
The string is separated at every comma, arguments containing a comma are 
misinterpreted.

So we'd think about another way delivering the arguments to load_multiboot.

-initrd is used passing multiboot modules, but multiboot modules aren't really 
initrd's

Multiboot modules are only loaded when qemu identifies the kernel as a 
Multiboot kernel.
It would be much easier to pass the modules to qemu using a commandline 
argument like -multiboot.
e.g.
qemu -kernel mymultibootkern -module "1.mod arg=bla" -module "2.mod arg=foo"

Well i didn't look at the global command line parsing of qemu, and i don't know 
how difficult it would be
to realize this. Anyone ideas?

--
Ralf

Re: [Qemu-devel] [PATCH] hw: improve multiboot module loading

On 07.04.2011, at 14:48, Stefan Hajnoczi wrote:

> Out of curiousity, why are you trying to kill spaces at all?
> 
> Why not just use a correct command-line to invoke QEMU?
> 
> Stefan

Well it took me 2 days to find out why -initrd "module1, module2" didn't work. 
If there's a space after the comma you'll always
get the error message "Failed to get  image size". And if you want to pass a 
comma in a multiboot argument you've no way to do this.
So -initrd"module1 settings=use_foo,use_bar" won't work!

--
Ralf

Re: [Qemu-devel] qemu-img segfaults on MIPS hosts due to not having an executable stack

2016-06-13 Thread Ralf Baechle

On Mon, Jun 13, 2016 at 04:16:02PM +0100, Peter Maydell wrote:

> On 13 June 2016 at 15:45, Daniel P. Berrange  wrote:
> > On Mon, Jun 13, 2016 at 03:11:08PM +0100, Peter Maydell wrote:
> >> QEMU currently allocates coroutine stacks with a plain g_malloc(),
> >> which makes them r/w but not exec. That's a bug in QEMU which we
> >> should fix (though I'm not sure how best to identify the required
> >> permissions for stacks). It's a bit unhelpful of the kernel to
> >> assume an executable stack and not give a useful diagnostic or
> >> failure mode if it's not true, though.
> >
> > I'd suggest we just #ifdef the code base on architecture, on that basis
> > all platforms except mips are probably happy with non-exec stack.
> 
> Have they really all got rid of signal handler trampolines?

Apparently Android wants a non-executable stack for security reasons.

That said, some special code such as GCC's nested functions may require
stack trampolines.  For such code there is the option to use the p_flags
of the PT_GNU_STACK program header to mark the stack executable.  One
way to do so is to pass the option "-z execstack" to ld or a ".section
.note.GNU-stack,"",@progbits" into the assembler code which is what GCC
will do when generating trampolines.

  Ralf

[Qemu-devel] [Bug 1395217] Re: Networking in qemu 2.0.0 and beyond is not compatible with Open Solaris (Illumos) 5.11

2015-04-30 Thread Ralf Münk

Hello to all, I confirm this bug in qemu.

12 different Linux versions/distributions and 1 Windows 7 VM  are running fine 
without any networking issue. 
Solaris 5.11 Version 11.2 can be installed (text version) and is running but 
network is broken.

DHCPOFFER will not be received by Solaris 5.11 VM's (RX not working)  for 
Automatic profile.
If DefaultFixed profile is online there is the same behavior. 
Arp table on Solaris containes the own entry which is completed.
If I ping another host, the IP will be added but no MAC, which indicates that 
also no ARP package will be received.  

I could NOT get it working with disabled x2apic (tested with different CPU 
types).
Is there something additional which has to be changed?

qemu version is 2.0.0+dfsg-2ubuntu1.10 @ ubuntu 14.04.2 LTS, Kernel
3.13.0-49-generic.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1395217

Title:
  Networking in qemu 2.0.0 and beyond is not compatible with Open
  Solaris (Illumos) 5.11

Status in QEMU:
  New

Bug description:
  The networking code in qemu in versions 2.0.0 and beyond is non-
  functional with Solaris/Illumos 5.11 images.

  Building 1.7.1, 2.0.0, 2.0.2, 2.1.2,and 2.2.0rc1with the following
  standard Slackware config:

  # From Slackware build tree . . . 
  ./configure \
--prefix=/usr \
--libdir=/usr/lib64 \
--sysconfdir=/etc \
--localstatedir=/var \
--enable-gtk \
--enable-system \
--enable-kvm \
--disable-debug-info \
--enable-virtfs \
--enable-sdl \
--audio-drv-list=alsa,oss,sdl,esd \
--enable-libusb \
--disable-vnc \
--target-list=x86_64-linux-user,i386-linux-user,x86_64-softmmu,i386-softmmu 
\
--enable-spice \
--enable-usb-redir 

  
  And attempting to run the same VM image with the following command (or via 
virt-manager):

  macaddress="DE:AD:BE:EF:3F:A4"

  qemu-system-x86_64 nex4x -cdrom /dev/cdrom -name "Nex41" -cpu Westmere
  -machine accel=kvm -smp 2 -m 4000 -net nic,macaddr=$macaddress  -net 
bridge,br=b
  r0 -net dump,file=/usr1/tmp/ -drive file=nex4x_d1 -drive 
file=nex4x_d2
   -enable-kvm

  Gives success on 1.7.1, and a deaf VM on all subsequent versions.

  Notable in validating my config, is that a Windows 7 image runs
  cleanly with networking on *all* builds, so my configuration appears
  to be good - qemu just hates Solaris at this point.

  Watching with wireshark (as well as pulling network traces from qemu
  as noted above) it appears that the notable difference in the two
  configs is that for some reason, Solaris gets stuck arping for it's
  own interface on startup, and never really comes on line on the
  network.  If other hosts attempt to ping the Solaris instance, they
  can successfully arp the bad VM, but not the other way around.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1395217/+subscriptions

[Qemu-devel] [Bug 726619] [NEW] loadvm does not load (offline) snapshot anymore

2011-02-28 Thread Ralf Haferkamp

Public bug reported:

qemu Version: 0.14.0
The problem is present in the current code from git master as well.

Loading a snapshot that was created while qemu was not running (using
qemu-img) does not seem to work anymore.

Using "loadvm " in the qemu monitor does not have the
desired effect. Not even an error message is displayed.

I was able to track down the problem (using git bisect) to this commit:
http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a

After reverting that commit in my local git checkout everything is
workin as expected again.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/726619

Title:
  loadvm does not load (offline) snapshot anymore

Status in QEMU:
  New

Bug description:
  qemu Version: 0.14.0
  The problem is present in the current code from git master as well.

  Loading a snapshot that was created while qemu was not running (using
  qemu-img) does not seem to work anymore.

  Using "loadvm " in the qemu monitor does not have the
  desired effect. Not even an error message is displayed.

  I was able to track down the problem (using git bisect) to this commit:
  
http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a

  After reverting that commit in my local git checkout everything is
  workin as expected again.

[Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of 64 bit

2008-02-19 Thread Ralf Baerwaldt

Hi !

I downloaded http://fabrice.bellard.free.fr/qemu/qemu-0.9.1-i386.tar.gz
and I'm using an AMD Opteron.

Is this version the correct one for my system ?

# file /usr/local/bin/qemu-system-x86_64
/usr/local/bin/qemu-system-x86_64: ELF 32-bit LSB executable, Intel
80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses
shared libs), stripped

but I expected someting like:

# file /usr/bin/qemu-system-x86_64
/usr/bin/qemu-system-x86_64: ELF 64-bit LSB executable, x86-64, version
1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs),
stripped

Ralf

[Qemu-devel] Re: 2.6.21 kernel on emulated/real Malta board

2007-06-18 Thread Ralf Baechle

On Sun, Jun 17, 2007 at 10:06:55AM +0200, Geert Uytterhoeven wrote:

> I guess it's just the printk buffer that's being output again to the new
> console, when the console subsystem switches from early console to real
> console.

Correct.

  Ralf

Re: [Qemu-devel] Qemu and Linux 2.4

2007-09-26 Thread Ralf Baechle

On Wed, Sep 26, 2007 at 08:25:18PM +0400, Alexander Voropay wrote:

> >>>- QEMU malta emulation is not really complete, to put it mildly
> >>Out of curiosity, what parts did you miss?
> >Like, for example, the PCI stuff. So I can use the network card.
> 
> PCI stuff in the QEMU/Malta works fine, but pseudo-bootrom
> does not perform PCI enumeration and leaves uninitialized PCI BARs.
> 
> Linux MIPS/Malta 2.4 can not perform PCI enumeration too.  The LANCE
> Ethernet driver *requres* a pre-initialized BARs. The situation even worse,
> since current Linux 2.4 can't be even built with NEW_PCI and PCI_AUTO
> options at all (due to linkage error).
> 
> http://www.linux-mips.org/wiki/PCI_Subsystem
> 
> There is the same PCI problem with NetBSD/evbmips and seems VxWorks/Malta.

Both CONFIG_PCI_NEW and PCI_AUTO were amazingly broken in both concept
and implementation.  It is possible to get them to work well for particular
configurations but for the general case nothing else nothing but rewrite
can rescue things.

> >And yes, I am aware of YAMON.
> 
> AFAIK, YAMON may runs on the MIPS hardware only, and may not
> be redistribuded in the source or binary form.

Alchemy boards run YAMON, too.

> ***
> This message and any attachments (the "message") are confidential and 
> intended solely for the addressees. Any unauthorised use or dissemination 

Soley for all the billion internet users, I assume ;-)

  Ralf

Re: [Qemu-devel] QEMU/MIPS & dyntick kernel

2007-10-02 Thread Ralf Baechle

On Tue, Oct 02, 2007 at 10:57:24PM +0200, Aurelien Jarno wrote:
> From: Aurelien Jarno <[EMAIL PROTECTED]>
> Date: Tue, 02 Oct 2007 22:57:24 +0200
> To: Alan Cox <[EMAIL PROTECTED]>
> CC: qemu-devel@nongnu.org, [EMAIL PROTECTED]
> Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Alan Cox a écrit :
> >> Well on real hardware, the instruction rate and the timer are linked:
> >> the timer run at half the speed of the CPU. As the corresponding
> >> assembly code is very small, only uses registers and is run in kernel
> >> mode, you know for sure that 48 cycles is more than enough.
> > 
> > What happens on NMI or if you take an ECC exception and scrubbing stall
> > off the memory controller while loading part of that cache line of code
> > into memory ?
> > 
> 
> The code returns -ETIME, and the function is run again with the minimum
> delay.
> 
> So as long as you don't have an exception every time, the code works.

The current setting should be safe on real hardware - but a value of
just 48 cycles for max_delta_ns is probably lower than the lowest
useful value, so I don't mind raising it.  This number really is a
tunable.

  Ralf

Re: [Qemu-devel] QEMU/MIPS & dyntick kernel

2007-10-15 Thread Ralf Baechle

On Mon, Oct 15, 2007 at 04:05:14PM +0100, Thiemo Seufer wrote:

> I found Qemu/MIPS locks up in the emulated kernel's calibrate_delay
> function. Switching the kernel option off works around the problem.

I still haven't patched up the issue which was causing the problem for
Aurel.  Is the slow execution of the emulator also the cause of what
you're seeing?

   Ralf

[Qemu-devel] Re: Qemu for MIPS

2005-06-09 Thread Ralf Baechle

On Tue, Jun 07, 2005 at 09:08:57PM +0200, Jocelyn Mayer wrote:

> > Oh, I've created a small Qemu/MIPS page on the Linux/MIPS Wiki at
> > http://www.linux-mips.org/wiki/index.php/Qemu.  It's a wiki so please feel
> > free to edit.

I've just put patches on that page.

> It would be great to publish them (or a link) on the qemu mailing list:
> .

I've added qemu-devel on the cc list.  I hope the list permits non-
subscriber postings.

> Then, more people may test and help for future development.
> Fabrice would be glad to see your code too, then I put him in CC.

  Ralf


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Qemu for MIPS

I've posted updated Qemu patches on

  ftp://ftp.linux-mips.org/pub/linux/mips/qemu
  http://www.linux-mips.org/wiki/index.php/Qemu

Enhancements over last week's patches:

 o The count/compare interrupt will now properly be delivered.
 o mfc0 will now return the proper value for the EXL and ERL flags
 o eret will now consider the value of ERL and EXL.
 o i8259 PIC is now properly cascaded to a CPU interrupt.
 o An ISA NE2000 card will now be emulated.
 o The CPU's random register now considers the value of the wired register

The new kernel patch is against the latest Linux/MIPS CVS kernel du jour
2.6.12-rc6 and has been updated to match Qemu's improvments.

Known bugs:

 o ll/sc don't use a ll_bit like the real hardware thus right now any atomic
   functions aren't really atomic.
 o ll/sc really should be watching a physical not a virtual address or they
   won't do much useful on any kind of shared memory structure.
 o MIPS documentation documents the lladdr register to contain the virtual
   address of the location being watched but about every implementation
   since the R4000 actually keeps the physical address there - and documents
   that as an erratum even though it actually the sensible thing to do.  We
   should do the same.  Fortunately nothing that I know of actually relies
   on the content of the lladdr register, so this one is cosmetic.

Last, not least, this is what you've been waiting for:

[EMAIL PROTECTED] qemu-mips]# mips-softmmu/qemu-system-mips -kernel 
~ralf/src/linux/linux-cvs/arch/mips/boot/vmlinux.bin -m 16 -nographic
nb_nics = 1
Connected to host network interface: tun0
/etc/qemu-ifup tun0
+ ifconfig tun0 up
+ brctl addbr qnet
device qnet already exists; can't create bridge with the same name
+ brctl addif qnet tun0
+ ifconfig qnet 172.20.0.1
(qemu) mips_r4k_init: start
mips_r4k_init: load BIOS '/usr/local/share/qemu/mips_bios.bin' size 131072
Linux version 2.6.12-rc5 ([EMAIL PROTECTED]) (gcc version 3.4.3) #257 Mon Jun 
13 02:58:23 BST 2005
CPU revision is: 00018000
Determined physical RAM map:
 memory: 0100 @  (usable)
On node 0 totalpages: 4096
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: console=ttyS0 debug ip=172.20.0.2:172.20.0.1::255.255.0.0
Primary instruction cache 2kB, physically tagged, 2-way, linesize 16 bytes.
Primary data cache 2kB, 2-way, linesize 16 bytes.
Synthesized TLB refill handler (19 instructions).
Synthesized TLB load handler fastpath (31 instructions).
Synthesized TLB store handler fastpath (31 instructions).
Synthesized TLB modify handler fastpath (30 instructions).
PID hash table entries: 128 (order: 7, 2048 bytes)
Using 100.000 MHz high precision timer.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 14464k/16384k available (1293k kernel code, 1900k reserved, 190k data, 
104k init, 0k highmem)
Calibrating delay loop... 144.58 BogoMIPS (lpj=722944)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
io scheduler noop registered
ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED])
Last modified Nov 1, 2000 by Paul Gortmaker
NE*000 ethercard probe at 0x300: 52 54 00 12 34 56
eth0: NE2000 found at 0x300, using IRQ 9.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
  device=eth0, addr=172.20.0.2, mask=255.255.0.0, gw=255.255.255.255,
 host=172.20.0.2, domain=, nis-domain=(none),
 bootserver=172.20.0.1, rootserver=172.20.0.1, rootpath=
Looking up port of RPC 13/2 on 172.20.0.1
Looking up port of RPC 15/1 on 172.20.0.1
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 104k freed
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Which is a bug - there is a valid root filesystem.  Something for tomorrow.

Enjoy,

  Ralf


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu for MIPS

On Mon, Jun 13, 2005 at 02:50:37PM +0300, Timo Savola wrote:

> Are there any plans for supporting user-mode MIPS emulation?

At some point certainly but right now my priority is full system emulation.

  Ralf


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Re: Qemu for MIPS

On Mon, Jun 13, 2005 at 12:44:09PM +0100, Dominic Sweetman wrote:

> > Known bugs:
> > 
> >  o ll/sc don't use a ll_bit like the real hardware thus right now any atomic
> >functions aren't really atomic.
> 
> I suppose you know that the CPUs all implement "break link on
> exception" by zeroing the link bit on an 'eret'?  That doesn't sound
> too hard...

It's not hard to add the llbit indeed - maybe I'm trying to hard to be
obscure use compatible.  Generally Qemu is trading the highest accuracy
of emulation for speed ...

> Arguably, an emulator should not provide the LLaddr register at all.
> It's optional and "only available for debug" - and probably such
> debugging is possible another way in an emulator.  Robust software
> shouldn't depend on assuming the contents make sense.

The only use I've seen for this register is having it being used as a
cp0 scratch register allowing to save the entire 31 GPRs.  Very old
Linux/MIPS used to do that but it doesn't match the reality of MIPS ABIs,
so I gave up on that very soon.  Like 11 years agp :)

> Not quite there yet... but well done, again.

  Ralf

___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu for MIPS

On Mon, Jun 13, 2005 at 02:47:48PM +0200, Hetz Ben Hamo wrote:

> Full system to boot Irix?

That would require emulation of an IRIX-supported platform.  Not undoable -
others have already gotten firmware as complex as the SGI ARC [1]
firmware to run on other emulators, I think it was mips64emul.

Windows NT for MIPS would be another thing to try ;-)

  Ralf

[1] And remember it writes ARC but pronounces A...


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH 3/3] Fix interrupt masking

2005-08-15 Thread Ralf Baechle

Only take interrupts that are actually enabled in the CPU's interrupt mask
in c0_status.

 cpu-exec.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: qemu-mips/cpu-exec.c
===
--- qemu-mips.orig/cpu-exec.c
+++ qemu-mips/cpu-exec.c
@@ -307,7 +307,7 @@ int cpu_exec(CPUState *env1)
 #elif defined(TARGET_MIPS)
 if ((interrupt_request & CPU_INTERRUPT_HARD) &&
 (env->CP0_Status & (1 << CP0St_IE)) &&
-(env->CP0_Cause & 0xFF00) &&
+(env->CP0_Status & env->CP0_Cause & 0xFF00) &&
 !(env->hflags & MIPS_HFLAG_EXL) &&
 !(env->hflags & MIPS_HFLAG_ERL) &&
 !(env->hflags & MIPS_HFLAG_DM)) {


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH 2/3] Add i8259 PIT to MIPS

2005-08-15 Thread Ralf Baechle

Add i8259 PIT to the MIPS configuration.  Not that the counter / compare
interrupt isn't nicer but the i8259 unfortunately a common peripheral in
MIPS systems and so it's probably a piece of code want just in case.

 Makefile.target |4 ++--
 hw/mips_r4k.c   |3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

Index: qemu-mips/hw/mips_r4k.c
===
--- qemu-mips.orig/hw/mips_r4k.c
+++ qemu-mips/hw/mips_r4k.c
@@ -7,6 +7,8 @@
 
 extern FILE *logfile;
 
+static PITState *pit;
+
 static void pic_irq_request(void *opaque, int level)
 {
 if (level) {
@@ -242,6 +244,7 @@ void mips_r4k_init (int ram_size, int vg
 isa_mem_base = 0x1000;
 
 isa_pic = pic_init(pic_irq_request, cpu_single_env);
+pit = pit_init(0x40, 0);
 serial_init(0x3f8, 4, serial_hds[0]);
 vga_initialize(NULL, ds, phys_ram_base + ram_size, ram_size, 
vga_ram_size, 0, 0);
Index: qemu-mips/Makefile.target
===
--- qemu-mips.orig/Makefile.target
+++ qemu-mips/Makefile.target
@@ -295,8 +295,8 @@ VL_OBJS+= mc146818rtc.o serial.o i8259.o
 VL_OBJS+= ppc_prep.o ppc_chrp.o cuda.o adb.o openpic.o heathrow_pic.o mixeng.o
 endif
 ifeq ($(TARGET_ARCH), mips)
-VL_OBJS+= mips_r4k.o dma.o vga.o serial.o ne2000.o i8259.o
-#VL_OBJS+= #ide.o pckbd.o i8254.o fdc.o m48t59.o
+VL_OBJS+= mips_r4k.o dma.o vga.o serial.o ne2000.o i8254.o i8259.o
+#VL_OBJS+= #ide.o pckbd.o fdc.o m48t59.o
 endif
 ifeq ($(TARGET_BASE_ARCH), sparc)
 ifeq ($(TARGET_ARCH), sparc64)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH 1/3] Fix MIPS counter / compare interrupt

2005-08-15 Thread Ralf Baechle

The count / compare interrupt is wired to the CPU's internal interrupt
controller, not a PIC.

 hw/mips_r4k.c|   10 --
 target-mips/helper.c |   12 +++-
 2 files changed, 19 insertions(+), 3 deletions(-)

Index: qemu-mips/hw/mips_r4k.c
===
--- qemu-mips.orig/hw/mips_r4k.c
+++ qemu-mips/hw/mips_r4k.c
@@ -72,7 +75,8 @@ void cpu_mips_store_count (CPUState *env
 void cpu_mips_store_compare (CPUState *env, uint32_t value)
 {
 cpu_mips_update_count(env, cpu_mips_get_count(env), value);
-pic_set_irq(5, 0);
+cpu_single_env->CP0_Cause &= ~0x8000;
+cpu_reset_interrupt(cpu_single_env, CPU_INTERRUPT_HARD);
 }
 
 static void mips_timer_cb (void *opaque)
@@ -86,7 +90,8 @@ static void mips_timer_cb (void *opaque)
 }
 #endif
 cpu_mips_update_count(env, cpu_mips_get_count(env), env->CP0_Compare);
-pic_set_irq(5, 1);
+cpu_single_env->CP0_Cause |= 0x8000;
+cpu_interrupt(cpu_single_env, CPU_INTERRUPT_HARD);
 }
 
 void cpu_mips_clock_init (CPUState *env)


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] Fix test for two's complement overflow

2006-02-15 Thread Ralf Baechle

Hi Fabrice,

A sequence like

addiu   $r0, $r0, 1
addi$r0, $r0, -1

would result in an integer overflow exception on MIPS targets.

This test fixes the test for a signed overflow done by the add, addi,
sub and subi instructions.

 target-mips/op.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

--- suckage/target-mips/op.c 5 Dec 2005 19:59:36 -
+++ suckage/target-mips/op.c 15 Feb 2006 16:15:45 -
@@ -202,13 +202,13 @@
 
 void op_addo (void)
 {
-target_ulong tmp;
+uint64_t tmp;
 
-tmp = T0;
-T0 += T1;
-if ((T0 >> 31) ^ (T1 >> 31) ^ (tmp >> 31)) {
+tmp = (int64_t) (int32_t) T0 + (int64_t) (int32_t) T1;
+if (((tmp >> 32) ^ (tmp >> 31)) & 1)
 CALL_FROM_TB1(do_raise_exception_direct, EXCP_OVERFLOW);
-}
+
+T0 = tmp;
 RETURN();
 }
 
@@ -222,11 +222,11 @@
 {
 target_ulong tmp;
 
-tmp = T0;
-T0 = (int32_t)T0 - (int32_t)T1;
-if (!((T0 >> 31) ^ (T1 >> 31) ^ (tmp >> 31))) {
+tmp = (int64_t) (int32_t) T0 - (int64_t) (int32_t) T1;
+if (((tmp >> 32) ^ (tmp >> 31)) & 1)
 CALL_FROM_TB1(do_raise_exception_direct, EXCP_OVERFLOW);
-}
+
+T0 = tmp;
 RETURN();
 }
 


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

QEMU+KVM on RISC-V + Hypervisor Extension

2022-03-12 Thread Ralf Ramsauer


Hi,

I'm trying to run Linux/QEMU+KVM inside an emulated
qemu-system-riscv64 VM (x86 host). On latest&greatest QEMU (1416688c53), 
I run Linux inside QEMU. On host side:


qemu-system-riscv64 -nographic \
-machine virt \
-cpu 'rv64,h=true' \
-smp 8 -m 8G \
-bios $latest_opensbi \
-kernel $latest_upstream_linux \
[…snip…]

Inside that machine, I boot Linux with KVM enabled:

[…]
[0.228939] kvm [1]: hypervisor extension available
[0.229000] kvm [1]: using Sv48x4 G-stage page table format
[0.229033] kvm [1]: VMID 14 bits available
[…]

KVM seems to load correctly. Inside that machine, I compiled QEMU from 
the same sources with the KVM accelerator enabled. When I try to start 
QEMU with KVM enabled, I get


./qemu-system-riscv64 -nographic \
-monitor none \
-machine virt \
-smp 1 -m 1G \
-bios ./pc-bios/opensbi-riscv64-generic-fw_dynamic.bin \
-serial stdio \
-enable-kvm

[ 4860.559194] kvm [9942]: VCPU exit error -95
[ 4860.584262] kvm [9942]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[ 4860.586839] kvm [9942]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0

on the ringbuffer, together with a register dump of qemu [1] on the 
console. Needless to say, but without -enable-kvm, it works fine.


As far as I see that, SCAUSE=0x14 reports a 'Instruction Guest PF', 
which would be kind of correct, if the guest's PC really tries to 
execute at phys 0x0. DRAM of the 'virt' machine definition should start 
at 0x8000, where OpenSBI resides. So I wonder if an erroneous reset 
PC might be the culprit…


Before digging deeper into that issue, I wanted to ask if Qemu/KVM 
inside an emulated riscv64+H-extension is actually supported, or if this 
is a known bug and has some ongoing work.


Thanks
  Ralf

[1]

 pc   
 mhartid  
 mstatus  0002
 mip  
 mie  
 mideleg  
 medeleg  
 mtvec
 stvec
 mepc 
 sepc 
 mcause   
 scause   
 mtval
 stval
 mscratch 
 sscratch 
 satp 
 x0/zero   x1/ra x2/sp 
 x3/gp
 x4/tp x5/t0 x6/t1 
 x7/t2
 x8/s0 x9/s1 x10/a0 
 x11/a1   bf00
 x12/a2    x13/a3    x14/a4 
 x15/a5   
 x16/a6    x17/a7    x18/s2 
 x19/s3   
 x20/s4    x21/s5    x22/s6 
 x23/s7   
 x24/s8    x25/s9    x26/s10 
 x27/s11  
 x28/t3    x29/t4    x30/t5 
 x31/t6

Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension

2022-03-15 Thread Ralf Ramsauer





On 15/03/2022 09:33, Anup Patel wrote:

On Tue, Mar 15, 2022 at 12:18 PM Alistair Francis  wrote:


On Sun, Mar 13, 2022 at 12:12 PM Ralf Ramsauer
 wrote:


Hi,

I'm trying to run Linux/QEMU+KVM inside an emulated
qemu-system-riscv64 VM (x86 host). On latest&greatest QEMU (1416688c53),
I run Linux inside QEMU. On host side:

qemu-system-riscv64 -nographic \
  -machine virt \
  -cpu 'rv64,h=true' \
  -smp 8 -m 8G \
  -bios $latest_opensbi \
  -kernel $latest_upstream_linux \
 […snip…]

Inside that machine, I boot Linux with KVM enabled:

[…]
[0.228939] kvm [1]: hypervisor extension available
[0.229000] kvm [1]: using Sv48x4 G-stage page table format
[0.229033] kvm [1]: VMID 14 bits available
[…]

KVM seems to load correctly. Inside that machine, I compiled QEMU from
the same sources with the KVM accelerator enabled. When I try to start
QEMU with KVM enabled, I get

./qemu-system-riscv64 -nographic \
 -monitor none \
 -machine virt \
 -smp 1 -m 1G \
 -bios ./pc-bios/opensbi-riscv64-generic-fw_dynamic.bin \
 -serial stdio \
 -enable-kvm


The QEMU RISC-V KVM support is quite new so I haven't got a chance
to play with it.


Btw, the kernel's KVM selftests seem to run.



Nevertheless, we should not pass any firmware when using KVM
so can you try "-bios none" ?


I have no kernel specified in the guest, so I'd then expect to boot into 
an completely empty machine (besides the tiny startup stub in the MROM). 
However, I still get the exact same error as mentioned in my initial mail.


Again, without "-enable-kvm", everything works as expected (i.e., I 
don't see any output, because there's basically no guest code to execute).


Just out of curiosity: if you don't pass a bios to the machine, what 
would then the boot sequence be?


Thanks
  Ralf



Regards,
Anup



[ 4860.559194] kvm [9942]: VCPU exit error -95
[ 4860.584262] kvm [9942]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[ 4860.586839] kvm [9942]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0

on the ringbuffer, together with a register dump of qemu [1] on the
console. Needless to say, but without -enable-kvm, it works fine.

As far as I see that, SCAUSE=0x14 reports a 'Instruction Guest PF',
which would be kind of correct, if the guest's PC really tries to
execute at phys 0x0. DRAM of the 'virt' machine definition should start
at 0x8000, where OpenSBI resides. So I wonder if an erroneous reset
PC might be the culprit…

Before digging deeper into that issue, I wanted to ask if Qemu/KVM
inside an emulated riscv64+H-extension is actually supported, or if this
is a known bug and has some ongoing work.


RISC-V KVM should work. I haven't had a chance to try it myself though.

I have CCed two people who hopefully can help.

Alistair



Thanks
Ralf

[1]

   pc   
   mhartid  
   mstatus  0002
   mip  
   mie  
   mideleg  
   medeleg  
   mtvec
   stvec
   mepc 
   sepc 
   mcause   
   scause   
   mtval
   stval
   mscratch 
   sscratch 
   satp 
   x0/zero   x1/ra x2/sp
 x3/gp
   x4/tp x5/t0 x6/t1
 x7/t2
   x8/s0 x9/s1 x10/a0
 x11/a1   bf00
   x12/a2    x13/a3    x14/a4
 x15/a5   
   x16/a6    x17/a7    x18/s2
 x19/s3   
   x20/s4    x21/s5    x22/s6
 x23/s7   
   x24/s8    x25/s9    x26/s10
 x27/s11  
   x28/t3    x29/t4    x30/t5
 x31/t6

Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension

2022-03-15 Thread Ralf Ramsauer





On 15/03/2022 13:25, Anup Patel wrote:

On Tue, Mar 15, 2022 at 5:47 PM Ralf Ramsauer
 wrote:




On 15/03/2022 09:33, Anup Patel wrote:

On Tue, Mar 15, 2022 at 12:18 PM Alistair Francis  wrote:


On Sun, Mar 13, 2022 at 12:12 PM Ralf Ramsauer
 wrote:


Hi,

I'm trying to run Linux/QEMU+KVM inside an emulated
qemu-system-riscv64 VM (x86 host). On latest&greatest QEMU (1416688c53),
I run Linux inside QEMU. On host side:

qemu-system-riscv64 -nographic \
   -machine virt \
   -cpu 'rv64,h=true' \
   -smp 8 -m 8G \
   -bios $latest_opensbi \
   -kernel $latest_upstream_linux \
  […snip…]

Inside that machine, I boot Linux with KVM enabled:

[…]
[0.228939] kvm [1]: hypervisor extension available
[0.229000] kvm [1]: using Sv48x4 G-stage page table format
[0.229033] kvm [1]: VMID 14 bits available
[…]

KVM seems to load correctly. Inside that machine, I compiled QEMU from
the same sources with the KVM accelerator enabled. When I try to start
QEMU with KVM enabled, I get

./qemu-system-riscv64 -nographic \
  -monitor none \
  -machine virt \
  -smp 1 -m 1G \
  -bios ./pc-bios/opensbi-riscv64-generic-fw_dynamic.bin \
  -serial stdio \
  -enable-kvm


The QEMU RISC-V KVM support is quite new so I haven't got a chance
to play with it.


Btw, the kernel's KVM selftests seem to run.



Nevertheless, we should not pass any firmware when using KVM
so can you try "-bios none" ?


I have no kernel specified in the guest, so I'd then expect to boot into
an completely empty machine (besides the tiny startup stub in the MROM).
However, I still get the exact same error as mentioned in my initial mail.


When KVM is enabled and the kernel is not provided, there is simply
nothing in Guest RAM (0x8000) or ROM (0x) which means
you are booting garbage.


In all machine models ROM is at 0x1000, afaict. This is also the 
DEFAULT_RESETVEC of Qemu/RiscV. At least those few instructions should 
execute.


Cf.
https://github.com/qemu/qemu/blob/master/hw/riscv/boot.c#L285
and
https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c#L1371





Again, without "-enable-kvm", everything works as expected (i.e., I
don't see any output, because there's basically no guest code to execute).


Strange, but even in this case you might be running garbage.


Yeah, and in case of !kvm, booting garbage results in no output. With 
kvm enabled, it faults.






Just out of curiosity: if you don't pass a bios to the machine, what
would then the boot sequence be?


For QEMU KVM:
1) There is no M-mode
2) Guest directly boots in S-mode
3) The SBI services are provided by in-kernel KVM module


Aaah! I understand. Thanks for the clarification.



You need to specify the Guest kernel using "-kernel" parameter when
using QEMU KVM.


Yikes, that one works!

qemu-system-riscv64 -monitor none \
-machine virt -smp 1 -m 1G \
-bios none -nographic -serial stdio \
-enable-kvm -kernel ./Image

[0.00] Linux version 5.17.0-rc7-00235-gaad611a868d1 
(ralf@redstone02) (riscv64-linux-gnu-gcc (Ubuntu 10.3.0-8ubuntu1) 
10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #10 SMP Sun Mar 13 
01:11:32 CET 2022

[0.00] Machine model: riscv-virtio,qemu
[0.00] efi: UEFI not found.
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x8000-0xbfff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8000-0xbfff]
[0.00] Initmem setup node 0 [mem 
0x8000-0xbfff]

[0.00] SBI specification v0.2 detected
[0.00] SBI implementation ID=0x3 Version=0x51100
[0.00] SBI TIME extension detected
[0.00] SBI IPI extension detected
[0.00] SBI RFENCE extension detected
[0.00] SBI HSM extension detected
[…]


I thought it'd be better to get OpenSBI running before even trying to 
pass a kernel. I didn't know that SBI services are emulated/moderated(?) 
by KVM, and that there must be no bios specified when using KVM. Will 
have a closer look at the code.


Anup, thank you!

  Ralf



Regards,
Anup



Thanks
Ralf



Regards,
Anup



[ 4860.559194] kvm [9942]: VCPU exit error -95
[ 4860.584262] kvm [9942]: SEPC=0x0 SSTATUS=0x24120 HSTATUS=0x2002001c0
[ 4860.586839] kvm [9942]: SCAUSE=0x14 STVAL=0x0 HTVAL=0x0 HTINST=0x0

on the ringbuffer, together with a register dump of qemu [1] on the
console. Needless to say, but without -enable-kvm, it works fine.

As far as I see that, SCAUSE=0x14 reports a 'Instruction Guest PF',
which would be kind of correct, if the guest's PC really tries to
execute at phys 0x0. DRAM of the 'virt' machine definition should start
at 0x8000, where OpenSBI resid

Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension

2022-03-15 Thread Ralf Ramsauer





On 15/03/2022 13:42, Peter Maydell wrote:

On Tue, 15 Mar 2022 at 12:29, Ralf Ramsauer
 wrote:

I have no kernel specified in the guest, so I'd then expect to boot into
an completely empty machine (besides the tiny startup stub in the MROM).
However, I still get the exact same error as mentioned in my initial mail.

Again, without "-enable-kvm", everything works as expected (i.e., I
don't see any output, because there's basically no guest code to execute).


Well, you'll always be trying to execute something, even if it's
all-zeroes. I dunno what RISC-V does with its encodings, but you
typically either end up in an infinite loop of taking exceptions
(if all-0s isn't a valid instruction) or else you just execute
through all of guest RAM (if it is something similar to a no-op).
In the latter scenario it's quite plausible that the guest ends
up doing something KVM doesn't expect, such as trying to execute
from an area of the address space where there is no RAM, or a device.
If so, "return failure from VCPU_RUN and QEMU aborts" is what I
think I would expect to see.

If I were you I would try it with some actual guest code loaded
at a location where there is RAM...


I guess you are right, and I think, together with the other mail, I now 
understand why I experienced a failure:


As Anup explained, there is no M-Mode, but I passed an OpenSBI BIOS. The 
initial MROM handed over to OpenSBI (located at RAM base 0x8000). At 
some point, OpenSBI threw an exception (maybe it accessed an CSR it is 
not allowed to, whatever), because it is in S-Mode. Exception vectors 
were not (yet) installed, but initialized with 0x0.


This is how I ended up with the PC at 0x0. Behind 0x0, there's no 
physical backing, and KVM threw an Instruction Guest PF (SCAUSE=0x14).


Didn't verify this, but this somehow sounds plausible to me.

Thanks!
  Ralf



-- PMM

Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension

2022-03-19 Thread Ralf Ramsauer





On 17/03/2022 10:45, Peter Maydell wrote:

On Wed, 16 Mar 2022 at 22:23, Alistair Francis  wrote:

Hmm... This seems like a bug. We shouldn't allow the user to specify a
`-bios` option if using KVM. Would you mind preparing a patch to catch
this?


You don't want to allow the possibility of a bios blob that expects
to run in S-mode, the way arm virt can run an EL1 UEFI BIOS ?


Valid point. In any case, if you wish, we could provide a patch for 
disallowing -bios in combination with -enable-kvm.


Thanks
  Ralf



thanks
-- PMM

Re: [EXT] Re: QEMU+KVM on RISC-V + Hypervisor Extension

On 21/03/2022 21:47, Palmer Dabbelt wrote:

On Sun, 20 Mar 2022 22:43:07 PDT (-0700), alistai...@gmail.com wrote:
On Thu, Mar 17, 2022 at 7:46 PM Peter Maydell
wrote:

On Wed, 16 Mar 2022 at 22:23, Alistair Francis
wrote:

> Hmm... This seems like a bug. We shouldn't allow the user to specify a
> `-bios` option if using KVM. Would you mind preparing a patch to catch
> this?

You don't want to allow the possibility of a bios blob that expects
to run in S-mode, the way arm virt can run an EL1 UEFI BIOS ?

Interesting. We could still allow that by using -device loader though.

If we load something in S mode it really is a kernel and not firmware,
so I think the -bios argument is a little misleading. We could make
-bios and -enable-kvm a warning instead, to discourage users from
providing OpenSBI, but still allow them to pass something.

We could handle this in OpenSBI: have it just detect that it's been
launched in S-mode and just jump to the payload.

To me not allowing it seems reasonable, and we can always re-allow it
in the future if there is a good use case.

That also seems fine to me. There'd be a lot of work involved in doing
anything useful with S-mode firmware, given that things aren't really
designed to work that way. Certainly a lot more work than re-enabling
this sort of flag, and while it might be a bit of a headache coupling
that to a QEMU source-level change my guess is that there'd need to be a
bunch of work done on new HW interfaces to make this useful so there'd
be QEMU changes to emulate those either way.

Having at least a warning seems prudent, as most users are going to end
up with a hang here and a silent hang is a headache for everyone.

Okay, my analysis was wrong, -bios is in fact already ignored when being
used in combination with -enable-kvm on the virt machine model. See:

https://git.qemu.org/?p=qemu.git;a=blob;f=hw/riscv/virt.c;h=da50cbed43ec54777992d40dbf158ec63fccef03;hb=HEAD#l1314

However, the bios will be silently ignored and dropped, which led me to
the mistake. I'll provide a patch that gives a warning to the user.

Ralf

Alistair

thanks
-- PMM

[PATCH] hw/riscv: virt: Warn the user if -bios is provided when using KVM

The -bios option is silently ignored if used in combination with -enable-kvm.
The reason is that the machine starts in S-Mode, and the bios typically runs in
M-Mode.

Warn the user that the bios won't be loaded.

Signed-off-by: Ralf Ramsauer 
---
 hw/riscv/virt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 4496a15346..a4d13114ee 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1312,6 +1312,9 @@ static void virt_machine_init(MachineState *machine)
  * when KVM is enabled.
  */
 if (kvm_enabled()) {
+if (machine->firmware && strcmp(machine->firmware, "none"))
+warn_report("BIOS is not supported in combination with KVM. "
+"Ignoring BIOS.");
 g_free(machine->firmware);
 machine->firmware = g_strdup("none");
 }
-- 
2.32.0

Re: [EXT] Re: [PATCH] hw/riscv: virt: Warn the user if -bios is provided when using KVM





On 23/03/2022 22:05, Alistair Francis wrote:

On Thu, Mar 24, 2022 at 3:13 AM Ralf Ramsauer
 wrote:


The -bios option is silently ignored if used in combination with -enable-kvm.
The reason is that the machine starts in S-Mode, and the bios typically runs in
M-Mode.

Warn the user that the bios won't be loaded.

Signed-off-by: Ralf Ramsauer 


Thanks for the patch.


---
  hw/riscv/virt.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 4496a15346..a4d13114ee 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1312,6 +1312,9 @@ static void virt_machine_init(MachineState *machine)
   * when KVM is enabled.
   */
  if (kvm_enabled()) {
+if (machine->firmware && strcmp(machine->firmware, "none"))


You need curly braces around the if statement. You can run checkpatch
on the patch to catch issues like this with:

git show | ./scripts/checkpatch.pl -


total: 0 errors, 0 warnings, 9 lines checked

Your patch has no obvious style problems and is ready for submission.




+warn_report("BIOS is not supported in combination with KVM. "
+"Ignoring BIOS.");


Maybe say

"Machine mode firmware is not supported in combination with KVM. Ignoring -bios"


Anyway, will provide a V2 with an improved warning message.

Thanks
  Ralf



Alistair


  g_free(machine->firmware);
  machine->firmware = g_strdup("none");
  }
--
2.32.0

[PATCH v2] hw/riscv: virt: Warn the user if -bios is provided when using KVM