Andy,
I just downloaded v0.9. I'll be setting it up on an ARM Linux board with QEMU, since I have only one Intel machine in the house. That one Intel board requires UEFI, so no joy there. Wonder if you've given much thought to UEFI?
My experiences with Visopsys install on QEMU virt disk
- ronaldlees
- Posts: 120
- Joined: Tue May 20, 2014 5:19 pm
Re: My experiences with Visopsys install on QEMU virt disk
Lots I've developed several UEFI loaders at work, and the Visopsys one is nearly finished ... but ...
32-bit UEFI firmware is vanishingly rare nowadays - even a few years ago - I've only ever used one, and even Windows theoretically (not really) didn't support 32-bit UEFI.
So, really, UEFI booting should come after the x86_64 kernel. And it makes sense to me to implement SMP before that, so I can keep myself disciplined about a multi-architectural framework.
These are the main low-level tasks for the 1.0 release. Which I hope happens faster than 0.8->0.9. Luckily we're not planning any new children around here.
Thanks for trying it!
Andy
- ronaldlees
- Posts: 120
- Joined: Tue May 20, 2014 5:19 pm
Re: My experiences with Visopsys install on QEMU virt disk
Hi Andy,
I tried the v0.9 version of Visopsys today, and it installed OK. It seems the interface of the installer is more "fluid" than it seemed to be the last time I installed Visopsys. Much better. Anyway, the system installed and booted OK with no network, but when I set QEMU to use the pcnet nic, I got debug messages about interrupt handling. Here's a screen shot (sorry for the poor picture):
. I switched the QEMU virtual nic to be an e1000 instead of the pcnet device. The system booted OK, but of course the network dialog in Visopsys then indicated that there were no supported nics found. Switching the pcnet device back into the config caused the interrupt situation again. Are you using a physical pcnet card for your tests?
- Ron
I tried the v0.9 version of Visopsys today, and it installed OK. It seems the interface of the installer is more "fluid" than it seemed to be the last time I installed Visopsys. Much better. Anyway, the system installed and booted OK with no network, but when I set QEMU to use the pcnet nic, I got debug messages about interrupt handling. Here's a screen shot (sorry for the poor picture):
. I switched the QEMU virtual nic to be an e1000 instead of the pcnet device. The system booted OK, but of course the network dialog in Visopsys then indicated that there were no supported nics found. Switching the pcnet device back into the config caused the interrupt situation again. Are you using a physical pcnet card for your tests?
- Ron
- ronaldlees
- Posts: 120
- Joined: Tue May 20, 2014 5:19 pm
Re: My experiences with Visopsys install on QEMU virt disk
I'm reading that Qemu and almost all other virtualization software has plenty of issues with interrupt virtualizations. Qemu was mentioned specifically as having such issues prior to v2.9. I'll check the version I'm using. OTOH, Visopsys v0.82 worked OK with pcnet. I think you're using VMware?
Re: My experiences with Visopsys install on QEMU virt disk
Hi Ron.ronaldlees wrote: ↑Wed Apr 29, 2020 9:27 pm when I set QEMU to use the pcnet nic, I got debug messages about interrupt handling. Here's a screen shot (sorry for the poor picture):
Argh. I saw a similar kind of thing with unhandled interrupts on my dev PC. That was when I (unknowingly) had my disk controller set to legacy IDE mode for some reason. I never did figure out why the interrupt storm was happening.
Anyway yes I normally use VMware. Just to double-check: 0.82 worked? Any chance you tried 0.85 with this setup? That's when I did a bunch of APIC work to try and sort out the interrupts.
I will try it here with Qemu and try to debug it.
Andy
Re: My experiences with Visopsys install on QEMU virt disk
Huh. It's working for me, I think, without all the interrupt problems. Well, DHCP times out, but that's something else about the network args.ronaldlees wrote: ↑Wed Apr 29, 2020 11:02 pm I'm reading that Qemu and almost all other virtualization software has plenty of issues with interrupt virtualizations. Qemu was mentioned specifically as having such issues prior to v2.9. I'll check the version I'm using. OTOH, Visopsys v0.82 worked OK with pcnet. I think you're using VMware?
I'm using the Qemu command that you gave us earlier in this thread. Is that the same command you've been using with 0.9?
- ronaldlees
- Posts: 120
- Joined: Tue May 20, 2014 5:19 pm
Re: My experiences with Visopsys install on QEMU virt disk
Hi Andy,
Yes, I used the command lines from the first page of this thread to run QEMU. Did you have the host networking set-up with the tun/tap, etc? I think QEMU may discard network args if it cannot find a hardware configuration that matches up with the args. In that case, maybe you'd be running without pcnet. Without pcnet, v0.9 works for me just fine, albeit without networking. In your QEMU setup, does Visopsys see the pcnet virtual nic?
- Ron
Yes, I used the command lines from the first page of this thread to run QEMU. Did you have the host networking set-up with the tun/tap, etc? I think QEMU may discard network args if it cannot find a hardware configuration that matches up with the args. In that case, maybe you'd be running without pcnet. Without pcnet, v0.9 works for me just fine, albeit without networking. In your QEMU setup, does Visopsys see the pcnet virtual nic?
- Ron
Re: My experiences with Visopsys install on QEMU virt disk
Hi Ron, thanks for getting back to me so quickly.
I'm a qemu noob, so I didn't do anything other than your 2 commands:
The galaxy of possible arguments to qemu are fairly daunting, but seems like there are a lot of cool virtual hardware options to experiment with.
I'm a qemu noob, so I didn't do anything other than your 2 commands:
It does see the pcnet device, and tries to enable it, although as I said it doesn't quite 'work' because it can't contact my DHCP server with these args. It times out.qemu-img create -f raw ./visopsys.img 200M
qemu-system-i386 -m 200M -netdev tap,id=t0,ifname=tap0,script=no,downscript=no -device pcnet,netdev=t0,id=nic0 -cdrom ./visopsys.iso -boot d -serial stdio -drive file=./visopsys.img,format=raw
The galaxy of possible arguments to qemu are fairly daunting, but seems like there are a lot of cool virtual hardware options to experiment with.
Re: My experiences with Visopsys install on QEMU virt disk
I do think that if I could reproduce this with qemu it would be very useful. I've got a user over in the Partition Logic forum with an apparent interrupt problem, and I'm hopeful that there's just some nuance of APIC setup (or PCI device setup, or interrupt acknowledgement) that I've missed.
As I said I only ever saw this on my dev workstation, with the AHCI controller set to IDE mode, and I could not for the life of me figure out why some devices just kept interrupting for no apparent reason, even when not enabled on the PCI bus. Debugging my dev workstation is awkward, though. I eventually gave up after about a week. But your thing looks like the same problem.
Are you using anything like KVM? I'm not, at this point.
As I said I only ever saw this on my dev workstation, with the AHCI controller set to IDE mode, and I could not for the life of me figure out why some devices just kept interrupting for no apparent reason, even when not enabled on the PCI bus. Debugging my dev workstation is awkward, though. I eventually gave up after about a week. But your thing looks like the same problem.
Are you using anything like KVM? I'm not, at this point.
- ronaldlees
- Posts: 120
- Joined: Tue May 20, 2014 5:19 pm
Re: My experiences with Visopsys install on QEMU virt disk
Well, currently I'm using native mode Qemu because my Odroids don't have the VT-x Intel hardware virtualization cpu extensions. For many operating systems, KVM would be a performance boost in Qemu. For Visopsys, I doubt that a person would notice much difference, but I could be wrong.
My trusty Qemu setup's SSD finally went belly up. So, I'm going to be on hold for a replacement before I can continue with testing. My normal source for hardware has been closed due to Corona, so maybe I'll have to do the online thing ...
My trusty Qemu setup's SSD finally went belly up. So, I'm going to be on hold for a replacement before I can continue with testing. My normal source for hardware has been closed due to Corona, so maybe I'll have to do the online thing ...