[Qemu-devel] about serial port support

[Qemu-devel] about serial port support

[Cai Qiang]

Hi everyone,
	I am doing qemu serial port support. It works like below:
1. in command line, -serial /dev/ttyS0 and so on
2. in vl.c, init the port
3. in hw/serial.c, when serial seting changed, notify vl.c also change host 
OS's seting.
	Is this feature useful? Is there any better implement? Any comments are 
welcome.

Best Regards

	Cai Qiang

Re: [Qemu-devel] about serial port support

[Jim C. Brown]

On Sun, Apr 03, 2005 at 06:43:12AM +0000, Cai Qiang wrote:
> 
> Hi everyone,
> 	I am doing qemu serial port support. It works like below:
> 1. in command line, -serial /dev/ttyS0 and so on
> 2. in vl.c, init the port
> 3. in hw/serial.c, when serial seting changed, notify vl.c also change host 
> OS's seting.
> 	Is this feature useful? Is there any better implement? Any comments are 
> welcome.
> 
> Best Regards
> 
> 	Cai Qiang
> 

This has been asked for many times, but you are the first to implement it.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

RE: [Qemu-devel] about serial port support

[Andreas Bollhalder]

Serial support is of course usefull. I know of some kind of debugging
over a serial port and if this could work between two qemu instances,
it would be nice.

About the implementation, I believe there are some cracks around which
could help you.

Andreas

> -----Original Message-----
> From: qemu-devel-bounces+bolle=geodb.org@nongnu.org 
> [mailto:qemu-devel-bounces+bolle=geodb.org@nongnu.org] On 
> Behalf Of Cai Qiang
> Sent: Sunday, April 03, 2005 8:43 AM
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] about serial port support
> 
> 
> *This message was transferred with a trial version of 
> CommuniGate(tm) Pro*
> 
> Hi everyone,
> 	I am doing qemu serial port support. It works like below:
> 1. in command line, -serial /dev/ttyS0 and so on
> 2. in vl.c, init the port
> 3. in hw/serial.c, when serial seting changed, notify vl.c 
> also change host 
> OS's seting.
> 	Is this feature useful? Is there any better implement? 
> Any comments are 
> welcome.
> 
> Best Regards
> 
> 	Cai Qiang
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

[Qemu-devel] FreeDOS Testimage

[Andreas Bollhalder]

Hello all

I have a simple disk image with the current FreeDOS kernel (2035a).
When loading FreeDOS with HIMEM, EMM386 and FDAPM together, I loose
the keyboard and QEMU freeze. I can't switch to the monitor nor the
other consoles (ser0, par0). I need to kill the QEMU process. This
happens on my WinXP host with all QEMU versions I have (from 0.6.1 to
daily builds from FreeOSZoo and my owns). I will verify on my Gentoo
machine at my work tomorrow.

The image can be downloaded here:

http://geodb.org/download/fdostest.zip (124kB)

Start QEMU with this image as the first hard disk. When starting, you
will be prompted for loading the three binaries HIMEM, EMM386 and
FDAPM. Keep in mind, that no keyboard driver is loaded (may need to
press Z for Yes...).

none -> OK, but CPU usage is 100%
FDAPM -> OK
HIMEM + FDAPM -> OK
HIMEM + EMM386 -> OK, but CPU usage is 100%
HIMEM + EMM386 + FDAPM -> freeze

I have the same effekt with DOSIDLE for FDAPM.

This files works on my P350 without a clue.

If someone could test and get an idea whats wrong, please let me know.

Andreas

Re: Re: [Qemu-devel] kqemu 0.6.2 and XP

[Andreas Bollhalder]

I tried the math on my WinXP host with Win2k guest.

When using the following math with my 8192MB QCOW image, QEMU refuse
to start:

1 Block = 512 Bytes

Cylinders = Blocks / (Heads * Sectors)

(kBytes * 2) / (16 * 63)
(8388608 kBytes * 2) / (16 * 63)

For 8192MB Image: -hdachs 16644,16,63


I brute forced the cylinder value, QEMU will start with a lower or
equal value of 16383 cylinders.

I made my own math based on this:

Cylinders = Blocks / (Heads * (Sectors + 1)) - 1

(kBytes * 2) / (16 * 64) - 1
(8388608 kBytes * 2) / (16 * 64) - 1

For 8192MB Image: -hdachs 16383,16,63


I'm realy confused about what's right or not. I created the image with
the QEMU Manager. Can anyone explain this ???

Andreas


Ben Taylor wrote:

> I forgot one very important part.  The calculation needs
> to be <img size in bytes> / (heads * sectors per cylinder 
> * 512 bytes) = cylinders. so in your case, the calculation is close

> well, the default sector size is 512, and you've done
> your sizing in number of 1k blocks, your calculations was
> close.  It should be:
>
>   blocks     secs/block      hds     sec/cyl
>
> (2 000 000   *   2 )    /  (   16   *   63 ) = 3968

> The first time I did the math, my 2g partition went
> to 8g partition when I used the -hdachs parameters
> cause I really screwed up the math.  (it appears if
> you mess your c-h-s values, your image since may
> change. :-)

> HTH, and sorry for the confusion.

> Ben

Re: Re: [Qemu-devel] kqemu 0.6.2 and XP

[Ben Taylor]

Michael Hoeller <Michael_Hoeller@hugoboss.com> wrote:

> Hello Ben,
> 
> I compiled with kqemu support - the version which works is the with or
> without kqemu?

Both.

> Just to double check, I created the virtual partition with dd of=win.img
> bs=1024 seek=2000000 count=0

I forgot one very important part.  The calculation needs
to be <img size in bytes> / (heads * sectors per cylinder 
* 512 bytes) = cylinders. so in your case, the calculation is close

> I am not sure to calculate the cylinders 2 000 000 / 16 / 63 = 1984,126
> ???

well, the default sector size is 512, and you've done
your sizing in number of 1k blocks, your calculations was
close.  It should be:

  blocks     secs/block      hds     sec/cyl

(2 000 000   *   2 )    /  (   16   *   63 ) = 3968

The first time I did the math, my 2g partition went
to 8g partition when I used the -hdachs parameters
cause I really screwed up the math.  (it appears if
you mess your c-h-s values, your image since may
change. :-)

HTH, and sorry for the confusion.

Ben
> 
> Thanks a lot
> Michael
> 
> Michael Hoeller <Michael_Hoeller@hugoboss.com>
> >
> > I have compiled qemu from the cvs 2004-04-14 and kqemu. Then tried to
> > install WinXP it hangs everytime after formating when it tries to copy
> the
> > install data.
> > I have startet with qemu  -m 512 -localtime -user-net -hda
> /data/winxp.img
> > -cdrom /dev/cdrom -k de -boot d
> > Did I missed a tricky option or is there prob?
> 
> How big is your virtual partition supposed to be? Take
> that value, divide by 16 and 63 and then add
> -hdachs <cylinder>,16,63 and see if that works. I'm
> not using anything special (other than stuff to make
> it work with Solaris), and I've gotten win98, win2k pro,
> win2k server, winxp home upgrade and win 2003 to
> install.  They don't always run right once I start
> mucking with them, but the great thing is you can
> keep a backup of the image in case you screw something
> up.
> 
> This has worked for me with the cvs code, and not
> including the patch that was posted today.
> 
> 
> Ben
> 
> 
> 
> 
> 
> This e-mail (and/or attachments) is confidential and may be privileged. Use or disclosure of it by anyone other than a designated addressee is unauthorized.
> If you are not an intended recipient, please delete this e-mail from the computer on which you received it. We thank you for notifying us immediately.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: Re: [Qemu-devel] kqemu 0.6.2 and XP

[Ben Taylor]

"Andreas Bollhalder" <bolle@geodb.org>
> 
> I tried the math on my WinXP host with Win2k guest.
> 
> When using the following math with my 8192MB QCOW image, QEMU refuse
> to start:
> 
> 1 Block = 512 Bytes
> 
> Cylinders = Blocks / (Heads * Sectors)
> 
> (kBytes * 2) / (16 * 63)
> (8388608 kBytes * 2) / (16 * 63)
> 
> For 8192MB Image: -hdachs 16644,16,63

Yeah. Sorry about that. You probably want to use
something like 64 heads and 63 or 255 sectors/cylinder
in this case.  I expect that 16000 heads is probably 
a bit much. IIRC, Solaris tends to barf on big
volumes that have really big c/h/s translations.

  
> I brute forced the cylinder value, QEMU will start with a lower or
> equal value of 16383 cylinders.

Very interesting.  Wonder if that's some of ide limit.

> 
> I made my own math based on this:
> 
> Cylinders = Blocks / (Heads * (Sectors + 1)) - 1
> 
> (kBytes * 2) / (16 * 64) - 1
> (8388608 kBytes * 2) / (16 * 64) - 1
> 
> For 8192MB Image: -hdachs 16383,16,63

well, you should be able to make it ~4100 cylinders
just by increasing the heads from 16 to 64.

> 
> 
> I'm realy confused about what's right or not. I created the image with
> the QEMU Manager. Can anyone explain this ???

I think the large number of cylinders is a *bad* thing.
Sorry if I don't have a more technical term. It's not
from looking at the code, but from field experience when
dealing with really big Luns on a SAN.

Ben
> 
> Andreas
> 
> 
> Ben Taylor wrote:
> 
> > I forgot one very important part.  The calculation needs
> > to be <img size in bytes> / (heads * sectors per cylinder 
> > * 512 bytes) = cylinders. so in your case, the calculation is close
> 
> > well, the default sector size is 512, and you've done
> > your sizing in number of 1k blocks, your calculations was
> > close.  It should be:
> >
> >   blocks     secs/block      hds     sec/cyl
> >
> > (2 000 000   *   2 )    /  (   16   *   63 ) = 3968
> 
> > The first time I did the math, my 2g partition went
> > to 8g partition when I used the -hdachs parameters
> > cause I really screwed up the math.  (it appears if
> > you mess your c-h-s values, your image since may
> > change. :-)
> 
> > HTH, and sorry for the confusion.
> 
> > Ben
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>