[SeaBIOS] Re: [PATCH] Preserve Xen DebugOutputPort
On Tue, Jun 16, 2020 at 10:31:17PM -0400, Jason Andryuk wrote:
> xen_preinit() runs early and changes DebugOutputPort. qemu_preinit() runs
> soon after. inb on DebugOutputPort doesn't work on Xen, so the check
> will always fail and DebugOutputPort will be cleared to 0 disabling
> output.
>
> Quick exit the function when running on Xen to preserve the modified
> DebugOutputPort.
>
> Signed-off-by: Jason Andryuk
> ---
> src/hw/serialio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/hw/serialio.c b/src/hw/serialio.c
> index 3163344..c6297bc 100644
> --- a/src/hw/serialio.c
> +++ b/src/hw/serialio.c
> @@ -106,6 +106,10 @@ u16 DebugOutputPort VARFSEG = 0x402;
> void
> qemu_debug_preinit(void)
> {
> +/* Xen already overrode DebugOutputPort in xen_preinit(). */
> +if (runningOnXen())
> +return;
Thanks. The code looks fine to me. However, I find the comment
confusing as this function only checks if output is enabled - it
doesn't check the validity of the port itself. Perhaps a comment like
"Xen doesn't support checking if debug output is active".
-Kevin
> +
> /* Check if the QEMU debug output port is active */
> if (CONFIG_DEBUG_IO &&
> inb(GET_GLOBAL(DebugOutputPort)) != QEMU_DEBUGCON_READBACK)
> --
> 2.25.1
> ___
> SeaBIOS mailing list -- seabios@seabios.org
> To unsubscribe send an email to seabios-le...@seabios.org
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] Preserve Xen DebugOutputPort
On Mon, Jun 22, 2020 at 8:40 PM Kevin O'Connor wrote:
>
> On Tue, Jun 16, 2020 at 10:31:17PM -0400, Jason Andryuk wrote:
> > xen_preinit() runs early and changes DebugOutputPort. qemu_preinit() runs
> > soon after. inb on DebugOutputPort doesn't work on Xen, so the check
> > will always fail and DebugOutputPort will be cleared to 0 disabling
> > output.
> >
> > Quick exit the function when running on Xen to preserve the modified
> > DebugOutputPort.
> >
> > Signed-off-by: Jason Andryuk
> > ---
> > src/hw/serialio.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/src/hw/serialio.c b/src/hw/serialio.c
> > index 3163344..c6297bc 100644
> > --- a/src/hw/serialio.c
> > +++ b/src/hw/serialio.c
> > @@ -106,6 +106,10 @@ u16 DebugOutputPort VARFSEG = 0x402;
> > void
> > qemu_debug_preinit(void)
> > {
> > +/* Xen already overrode DebugOutputPort in xen_preinit(). */
> > +if (runningOnXen())
> > +return;
>
> Thanks. The code looks fine to me. However, I find the comment
> confusing as this function only checks if output is enabled - it
> doesn't check the validity of the port itself. Perhaps a comment like
> "Xen doesn't support checking if debug output is active".
Sure, I can change it. The other part I was trying to convey is that
even though Xen uses QEMU, and this function is prefixed with qemu_,
DebugOutputPort is different and cannot be checked. Since
DebugOutputPort is set right above this function, a reader may not
expect it to have changed. Having said that, your wording clearly
explains why Xen is leaving this function early.
Thanks,
Jason
___
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS and superformatted floppies
On Sat, Jun 20, 2020 at 10:12:51PM +0300, Mike Banon wrote: > > Well, I suspect for these use cases it'll be *alot* easier to add emulated > > harddisk support instead. > > It requires coding for SeaBIOS Same is true for superfloppy support. And testing this is much more difficult. Physical floppies are pretty much dead these days, and I doubt qemu can properly emulate all those tricks which superfloppy formats are using. Also: why invest much effort to squeeze a limited amount of additional capacity out of floppies if you can effectively remove all your capacity issues by just using hd images instead? > + asking the floppy OS authors to > release it as an HDD image (how many will do this?). Don't they already do this? How do you boot a floppy OS without a floppy drive? Don't they have usb stick images for that? Such an image effectively is an hd image ... > Meanwhile, support for floppies is already there - including the > double sized ones (2.88MB), it just needs an improvement The superfloppy improvements I remember (probably incomplete): (1) Most floppies and drives are tolerant enough for a few extra tracks, so use -- say -- 82 instead of 80 tracks. (2) Tweak timings a bit to squeeze one or two more sectors on each track. (3) Use 2048-sized sectors instead of 512 (less sync info needed -> more space for data). (4) Booting from 2048 sector floppies doesn't work, so use a 512-sector format for track 0 with boot block and superfloppy driver and 2048 for all other tracks. (1) looks easy, maybe even works without code changes, and given this is all virtual anyway if we are talking about floppy images you can probably add more than just 2-3 tracks without much trouble. (2) has effects on chs calculations, so I guess that one doesn't work with seabios right now. (4) is hard for images, and (3) without (4) is useless if you want boot from these floppies, so I guess that isn't used any more these days? take care, Gerd ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: SeaBIOS and superformatted floppies
On Mon 22 Jun 2020 at 10:58, Gerd Hoffmann wrote: On Sat, Jun 20, 2020 at 10:12:51PM +0300, Mike Banon wrote: > Well, I suspect for these use cases it'll be *alot* easier to add emulated harddisk support instead. It requires coding for SeaBIOS Same is true for superfloppy support. And testing this is much more difficult. Physical floppies are pretty much dead these days, and I doubt qemu can properly emulate all those tricks which superfloppy formats are using. That much is true: QEMU only supports logically-addressed disk images with a uniform sector size (and probably only 512-byte sectors, I have not checked thoroughly). The floppy controller emulation code looks at the size of the disk image and tries to match it against a table of known geometries I linked in my first message; a matched geometry is then presented to the guest – as in, if the guest assumes that geometry when accessing the drive, the accesses will be dispatched to the expected logical sectors of the image. Some of those known geometries correspond to superformats. Meanwhile in the guest, SeaBIOS does the same thing in reverse: when the floppy driver is initialised, a fixed geometry is assigned to each floppy drive[0], which is later used to validate CHS addresses and convert them into LBA[1], before dispatching the access to the floppy driver which converts LBA back into CHS when communicating with the hardware[2]. Not only is this back-and-forth rather silly, it causes problems when the geometry of the actual diskette in the drive does not match this made-up logical geometry, like when a virtual 23 × 80 × 2 disk image appears in a 1440 KiB drive (which SeaBIOS thinks should only ever deal with 18 × 80 × 2 disks). [0]: https://git.seabios.org/cgit/seabios.git/tree/src/hw/floppy.c?h=af0daeb2687ad2595482b8a71b02a082a5672ceb#n109 [1]: https://git.seabios.org/cgit/seabios.git/tree/src/disk.c?h=af0daeb2687ad2595482b8a71b02a082a5672ceb#n138 [2]: https://git.seabios.org/cgit/seabios.git/tree/src/hw/floppy.c?h=af0daeb2687ad2595482b8a71b02a082a5672ceb#n571 Also: why invest much effort to squeeze a limited amount of additional capacity out of floppies if you can effectively remove all your capacity issues by just using hd images instead? In my case, the effort wasn’t all that big; all I did was patch SeaBIOS not to convert CHS addresses to LBA and back when accessing floppy drives. Less than a 100 lines of code were changed. It’s a pretty dirty hack though, and you probably won’t take it, so I wrote this report to put the issue on the record so that it can be fixed properly. I realise supporting superformats on bare hardware would be much more effort and I’m not demanding it done immediately, but it’s probably worth having on the record too. And the reason I want to have large floppy images is that I want to use hard disk images for something else. Regards, —f ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
