[9fans] Parallels Vesa driver question

[9fans] Parallels Vesa driver question

[Daniel Lyons]

Hi,

I installed Plan 9 under Parallels 3 back in November of last year and  
it worked without a hitch. I tried to install another copy tonight and  
the bitmapped display isn't working in the new one, I just get a pure  
black screen after any aux/vga command that it thinks will succeed. I  
found I can reproduce that behavior by building and running a new  
kernel in the old install. Any ideas what has happened since November  
in the kernel with respect to Vesa and Parallels? I'd be more than  
happy to debug this issue if I could get a little guidance. I didn't  
see anything in the archives about this problem. Alternatively, does  
anyone know if Parallels 4 works with a current kernel? If so I'll  
probably just upgrade to that; I've been holding off for a good reason  
to.

Thanks,

—
Daniel Lyons

Re: [9fans] Parallels Vesa driver question

[erik quanstrom]

On Sun Aug  2 05:39:10 EDT 2009, fusion@storytotell.org wrote:
> Hi,
>
> I installed Plan 9 under Parallels 3 back in November of last year and
> it worked without a hitch. I tried to install another copy tonight and
> the bitmapped display isn't working in the new one, I just get a pure
> black screen after any aux/vga command that it thinks will succeed. I
> found I can reproduce that behavior by building and running a new
> kernel in the old install. Any ideas what has happened since November
> in the kernel with respect to Vesa and Parallels? I'd be more than
> happy to debug this issue if I could get a little guidance. I didn't
> see anything in the archives about this problem. Alternatively, does
> anyone know if Parallels 4 works with a current kernel? If so I'll
> probably just upgrade to that; I've been holding off for a good reason
> to.

two things: mtrr and adding a vesaflush command.  it doesn't quite make
sense to me that this would break parallels, unless there is something
funky about
- mtrr ranges with parallels.
- parallels vesa
- plan 9 vesa support

the easiest thing to do would be to comment out vesaflush and
see what happens.  without pawing through the standard, it may
be that vesaflush is optionally supported and parallels doesn't support it.

- erik

; diff -c vgavesa.c /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c
vgavesa.c:13,21 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:13,18
  #include <cursor.h>
  #include "screen.h"

-
- static void *hardscreen;
-
  #define WORD(p) ((p)[0] | ((p)[1]<<8))
  #define LONG(p) ((p)[0] | ((p)[1]<<8) | ((p)[2]<<16) | ((p)[3]<<24))
  #define PWORD(p, v) (p)[0] = (v); (p)[1] = (v)>>8
vgavesa.c:83,89 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:80,86
  }

  static void
- vesalinear(VGAscr *, int, int)
+ vesalinear(VGAscr* scr, int, int)
  {
  	int i, mode, size;
  	uchar *p;
vgavesa.c:130,169 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:127,135
  		size = ROUND(size, 1024*1024);

  havesize:
- 	if(size > 16*1024*1024)		/* probably arbitrary; could increase */
- 		size = 16*1024*1024;
- 	hardscreen = vmap(paddr, size);
- 	mtrr(paddr, size, "wc");
- //	vgalinearaddr(scr, paddr, size);
+ 	vgalinearaddr(scr, paddr, size);
  }

- static void
- vesaflush(VGAscr *scr, Rectangle r)
- {
- 	int t, w, wid, off;
- 	ulong *hp, *sp, *esp;
-
- 	if(rectclip(&r, scr->gscreen->r) == 0)
- 		return;
-
- 	hp = hardscreen;
- 	sp = (ulong*)(scr->gscreendata->bdata + scr->gscreen->zero);
- 	t = (r.max.x * scr->gscreen->depth + 2*BI2WD-1) / BI2WD;
- 	w = (r.min.x * scr->gscreen->depth) / BI2WD;
- 	w = (t - w) * BY2WD;
- 	wid = scr->gscreen->width;
- 	off = r.min.y * wid + (r.min.x * scr->gscreen->depth) / BI2WD;
-
- 	hp += off;
- 	sp += off;
- 	esp = sp + Dy(r) * wid;
- 	while(sp < esp){
- 		memmove(hp, sp, w);
- 		hp += wid;
- 		sp += wid;
- 	}
- }
-
  VGAdev vgavesadev = {
  	"vesa",
  	0,
vgavesa.c:174,178 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/vgavesa.c:140,145
  	0,
  	0,
  	0,
- 	vesaflush,
+ 	0,
  };

Re: [9fans] Parallels Vesa driver question

[Daniel Lyons]

Erik,

Thanks for your speedy assistance! I think the two things are closely  
interrrelated via the global variable hardscreen. Reverting this file  
solved the problem. I wouldn't be surprised if there were something  
weird about Parallels' MTRR support, and since this isn't the current  
version it's not likely to get any better. If anyone's using Parallels  
4 and not running into this issue, I'd love to know.

Also, are the old sources available online somewhere so I can do this  
kind of diff in the future on my own?

Thanks again,

On Aug 2, 2009, at 11:06 AM, erik quanstrom wrote:

> On Sun Aug  2 05:39:10 EDT 2009, fusion@storytotell.org wrote:
>> Hi,
>>
>> I installed Plan 9 under Parallels 3 back in November of last year  
>> and
>> it worked without a hitch. I tried to install another copy tonight  
>> and
>> the bitmapped display isn't working in the new one, I just get a pure
>> black screen after any aux/vga command that it thinks will succeed. I
>> found I can reproduce that behavior by building and running a new
>> kernel in the old install. Any ideas what has happened since November
>> in the kernel with respect to Vesa and Parallels? I'd be more than
>> happy to debug this issue if I could get a little guidance. I didn't
>> see anything in the archives about this problem. Alternatively, does
>> anyone know if Parallels 4 works with a current kernel? If so I'll
>> probably just upgrade to that; I've been holding off for a good  
>> reason
>> to.
>
> two things: mtrr and adding a vesaflush command.  it doesn't quite  
> make
> sense to me that this would break parallels, unless there is something
> funky about
> - mtrr ranges with parallels.
> - parallels vesa
> - plan 9 vesa support
>
> the easiest thing to do would be to comment out vesaflush and
> see what happens.  without pawing through the standard, it may
> be that vesaflush is optionally supported and parallels doesn't  
> support it.
>
> - erik
>
> ; diff -c vgavesa.c /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/ 
> vgavesa.c
> vgavesa.c:13,21 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/ 
> vgavesa.c:13,18
>  #include <cursor.h>
>  #include "screen.h"
>
> -
> - static void *hardscreen;
> -
>  #define WORD(p) ((p)[0] | ((p)[1]<<8))
>  #define LONG(p) ((p)[0] | ((p)[1]<<8) | ((p)[2]<<16) | ((p)[3]<<24))
>  #define PWORD(p, v) (p)[0] = (v); (p)[1] = (v)>>8
> vgavesa.c:83,89 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/ 
> vgavesa.c:80,86
>  }
>
>  static void
> - vesalinear(VGAscr *, int, int)
> + vesalinear(VGAscr* scr, int, int)
>  {
>  	int i, mode, size;
>  	uchar *p;
> vgavesa.c:130,169 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/ 
> vgavesa.c:127,135
>  		size = ROUND(size, 1024*1024);
>
>  havesize:
> - 	if(size > 16*1024*1024)		/* probably arbitrary; could increase */
> - 		size = 16*1024*1024;
> - 	hardscreen = vmap(paddr, size);
> - 	mtrr(paddr, size, "wc");
> - //	vgalinearaddr(scr, paddr, size);
> + 	vgalinearaddr(scr, paddr, size);
>  }
>
> - static void
> - vesaflush(VGAscr *scr, Rectangle r)
> - {
> - 	int t, w, wid, off;
> - 	ulong *hp, *sp, *esp;
> -
> - 	if(rectclip(&r, scr->gscreen->r) == 0)
> - 		return;
> -
> - 	hp = hardscreen;
> - 	sp = (ulong*)(scr->gscreendata->bdata + scr->gscreen->zero);
> - 	t = (r.max.x * scr->gscreen->depth + 2*BI2WD-1) / BI2WD;
> - 	w = (r.min.x * scr->gscreen->depth) / BI2WD;
> - 	w = (t - w) * BY2WD;
> - 	wid = scr->gscreen->width;
> - 	off = r.min.y * wid + (r.min.x * scr->gscreen->depth) / BI2WD;
> -
> - 	hp += off;
> - 	sp += off;
> - 	esp = sp + Dy(r) * wid;
> - 	while(sp < esp){
> - 		memmove(hp, sp, w);
> - 		hp += wid;
> - 		sp += wid;
> - 	}
> - }
> -
>  VGAdev vgavesadev = {
>  	"vesa",
>  	0,
> vgavesa.c:174,178 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/ 
> vgavesa.c:140,145
>  	0,
>  	0,
>  	0,
> - 	vesaflush,
> + 	0,
>  };
>

—
Daniel Lyons

Re: [9fans] Parallels Vesa driver question

[Steve Simon]

> Also, are the old sources available online somewhere so I can do this
> kind of diff in the future on my own?

you can use history(1) and yesterday(1) against sources.

9fs sources
history -D sourcesdump /n/sources/plan9/sys/src/9/pc/vgavesa.c

-Steve

Re: [9fans] Parallels Vesa driver question

[erik quanstrom]

> Erik,
>
> Thanks for your speedy assistance! I think the two things are closely
> interrrelated via the global variable hardscreen. Reverting this file
> solved the problem. I wouldn't be surprised if there were something
> weird about Parallels' MTRR support, and since this isn't the current
> version it's not likely to get any better. If anyone's using Parallels
> 4 and not running into this issue, I'd love to know.

you're welcome.

but if you wouldn't mind, would you try the new source but modify
it by replacing the vgavesaflush in the following diff with "0"?

> > vgavesa.c:174,178 - /n/sourcesdump/2008/1101/plan9/sys/src/9/pc/
> > vgavesa.c:140,145
> >  	0,
> >  	0,
> >  	0,
> > - 	vesaflush,
> > + 	0,
> >  };

the reason for this test would be to see if the problem is with vesaflush
or the mtrrs.

- erik

Re: [9fans] Parallels Vesa driver question

[Daniel Lyons]

On Aug 2, 2009, at 3:41 PM, erik quanstrom wrote:

>> Erik,
>>
>> Thanks for your speedy assistance! I think the two things are closely
>> interrrelated via the global variable hardscreen. Reverting this file
>> solved the problem. I wouldn't be surprised if there were something
>> weird about Parallels' MTRR support, and since this isn't the current
>> version it's not likely to get any better. If anyone's using  
>> Parallels
>> 4 and not running into this issue, I'd love to know.
>
> you're welcome.
>
> but if you wouldn't mind, would you try the new source but modify
> it by replacing the vgavesaflush in the following diff with "0"?

Yes, this alone is not sufficient to fix the problem, which I believe  
confirms your suspicion that there is a defect in either Parallel's  
MTRR or Plan 9's Vesa MTRR. My money would be on Parallels, since they  
have a reputation for building the VM to support Windows first.

Again, thanks! Hopefully I'll be able to afford a copy of the new  
version of Parallels in a little while and perhaps that will help  
further isolate the problem.

—
Daniel Lyons

Re: [9fans] Parallels Vesa driver question

[Balwinder S Dheeman]

On 08/02/2009 03:10 PM, Daniel Lyons wrote:
> Hi,
>
> I installed Plan 9 under Parallels 3 back in November of last year and
> it worked without a hitch. I tried to install another copy tonight and
> the bitmapped display isn't working in the new one, I just get a pure
> black screen after any aux/vga command that it thinks will succeed. I
> found I can reproduce that behavior by building and running a new kernel
> in the old install. Any ideas what has happened since November in the
> kernel with respect to Vesa and Parallels? I'd be more than happy to
> debug this issue if I could get a little guidance. I didn't see anything
> in the archives about this problem. Alternatively, does anyone know if
> Parallels 4 works with a current kernel? If so I'll probably just
> upgrade to that; I've been holding off for a good reason to.

A new faster vesa driver was added a few days ago, see
http://www.google.com/search?q=group%3A+comp.os.plan9+faster+vesa+driver

I also faced a similar problem on Plan9 running under QEMU, switching
back to xga solved the problem temporally, but this, skipping over and,
or ignoring bugs or compatibility issues in a new driver is definitely
not a solution :(

--
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

Re: [9fans] Parallels Vesa driver question

[Richard Miller]

> Hopefully I'll be able to afford a copy of the new
> version of Parallels in a little while and perhaps that will help
> further isolate the problem.

It's not just Parallels.  The new vgavesa also fails to work on
my VIA Epia MS10000 motherboard - even with the "vesaflush" table
entry removed.

I think the mtrr is not safe for all hardware variants.

Re: [9fans] Parallels Vesa driver question

[erik quanstrom]

On Mon Aug  3 05:27:06 EDT 2009, 9fans@hamnavoe.com wrote:
> > Hopefully I'll be able to afford a copy of the new
> > version of Parallels in a little while and perhaps that will help
> > further isolate the problem.
>
> It's not just Parallels.  The new vgavesa also fails to work on
> my VIA Epia MS10000 motherboard - even with the "vesaflush" table
> entry removed.
>
> I think the mtrr is not safe for all hardware variants.

strange.

could one of you having trouble with vesa + mtrr try
vesa + the pat patch on sources in the saved patch
directory?

- erik

Re: [9fans] Parallels Vesa driver question

[ron minnich]

Given these systems with mtrr issues.

Would it be possible to get:
- output from pci so we can see what memory ranges are in use on your machine
- how much memory
- what the mtrrs look like once set up

ron

Re: [9fans] Parallels Vesa driver question

[geoff]

Plan 9, including vga, runs fine in Parallels 4.

The new vesa driver will only use mtrrs if the cpuid
instruction says that they exist.

Re: [9fans] Parallels Vesa driver question

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Wow....  Where's parallels 4.  I doubt I qualify for a free one.  And VMWare
Fusion really sucks with Plan 9 at the moment :-(
Dave

On Mon, Aug 3, 2009 at 7:36 PM, <geoff@plan9.bell-labs.com> wrote:

> Plan 9, including vga, runs fine in Parallels 4.
>
> The new vesa driver will only use mtrrs if the cpuid
> instruction says that they exist.
>
>

[-- Attachment #2: Type: text/html, Size: 645 bytes --]

Re: [9fans] Parallels Vesa driver question

[Daniel Lyons]

On Aug 3, 2009, at 10:30 AM, ron minnich wrote:

> Given these systems with mtrr issues.
>
> Would it be possible to get:
> - output from pci so we can see what memory ranges are in use on  
> your machine

0.2.0:	vid  03.00.00 1ab8/1131  11 0:00004001 256 1:c0000000 16777216  
2:00004401 16
0.3.0:	brg  06.80.00 1ab8/1112   9
0.30.0:	brg  06.00.00 8086/1130 255
0.31.0:	brg  06.01.00 8086/2440 255
0.31.1:	disk 01.01.80 8086/244b 255 4:00005001 16
0.31.5:	aud  04.01.00 8086/2445   9 0:00005401 256 1:00005801 64
0.5.0:	net  02.00.00 10ec/8029  10 0:00004c01 32

> - how much memory

256 MB, but that's arbitrary; just the preference I have set in  
Parallels.

> - what the mtrrs look like once set up

I don't know how to obtain this information, but would be glad to  
supply it. Also, forgive my ignorance, but isn't there a chicken-and- 
egg problem, since if the MTRRs are set up in vgavesa.c, my display is  
unusable? Or is there a special way to bail out to the text mode when  
the display is screwed up?

Thanks again,

—
Daniel Lyons

Re: [9fans] Parallels Vesa driver question

[Daniel Lyons]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]


On Aug 3, 2009, at 9:12 PM, David Leimbach wrote:

> Wow....  Where's parallels 4.  I doubt I qualify for a free one.   
> And VMWare Fusion really sucks with Plan 9 at the moment :-(


You could always try Q: http://www.kju-app.org/. I find it unbearably  
slow but it is free. I thought VirtualBox was allergic to Plan 9 but I  
might try again now that I know what the problem is and how to work  
around it.

The Parallels site is here: http://www.parallels.com/products/desktop/  
but they want $80 (or $50, if you're merely upgrading). I hate to  
recommend it because of their indifference (sometimes bordering on  
hate) towards their customers but it does seem to be the fastest Mac  
Plan 9 emulator I've had success with so far. As I said before,  
Windows is about their only interest, if that's is something you need  
on your Mac.

—
Daniel Lyons


[-- Attachment #2: Type: text/html, Size: 6991 bytes --]

Re: [9fans] Parallels Vesa driver question

[Bakul Shah]

On Mon, 03 Aug 2009 20:12:08 PDT David Leimbach <leimy2k@gmail.com>  wrote:
> Wow....  Where's parallels 4.  I doubt I qualify for a free one.  And VMWare
> Fusion really sucks with Plan 9 at the moment :-(

qemu works well enough for me on FreeBSD & Linux but not on a
Mac.  VirtualBox doesn't run plan9 but it runs FreeBSD, Linux
and Windows fairly well so may be there is hope.  There is an
open source version of VirtualBox that might be worth
tinkering with.

Re: [9fans] Parallels Vesa driver question

[Daniel Lyons]

On Aug 3, 2009, at 5:20 AM, erik quanstrom wrote:
> strange.
>
> could one of you having trouble with vesa + mtrr try
> vesa + the pat patch on sources in the saved patch
> directory?


I fear I may not have applied the patch correctly:

/sys/src/9/pc% mk CONF=pcf
8c -FTVw devarch.c
devarch.c:733 not enough function arguments: cpuid
devarch.c:733 argument prototype mismatch "IND ULONG" for "IND INT":  
cpuid
devarch.c:739 argument prototype mismatch "INT" for "IND CHAR": cpuid
devarch.c:739 not enough function arguments: cpuid
devarch.c:739 argument prototype mismatch "IND ULONG" for "IND INT":  
cpuid
devarch.c:869 function args not checked: mtrrprint
devarch.c:951 function args not checked: mtrr
mk: 8c -FTVw devarch.c  : exit status=rc 1227: 8c 1229: error

I copied /n/sources/patch/saved/pat/*.[ch] to /sys/src/9/pc ... What  
is the correct procedure here?

Thanks again,

—
Daniel Lyons

Re: [9fans] Parallels Vesa driver question

[erik quanstrom]

> I fear I may not have applied the patch correctly:
>
> /sys/src/9/pc% mk CONF=pcf
> 8c -FTVw devarch.c
> devarch.c:733 not enough function arguments: cpuid
> devarch.c:733 argument prototype mismatch "IND ULONG" for "IND INT":
> cpuid
> devarch.c:739 argument prototype mismatch "INT" for "IND CHAR": cpuid
> devarch.c:739 not enough function arguments: cpuid
> devarch.c:739 argument prototype mismatch "IND ULONG" for "IND INT":
> cpuid
> devarch.c:869 function args not checked: mtrrprint
> devarch.c:951 function args not checked: mtrr
> mk: 8c -FTVw devarch.c  : exit status=rc 1227: 8c 1229: error
>
> I copied /n/sources/patch/saved/pat/*.[ch] to /sys/src/9/pc ... What
> is the correct procedure here?

your procedure was correct — assuming that the patch was made
against the current sources snapshot.  a more robust but
much more involved technique is to diff the x.c s against the x.c.orig s and
apply those diffs to your current setup.

i dropped a devarch.c in /n/sources/contrib/quanstro/devarch.c.  hopefully
that will make things easier.

- erik

Re: [9fans] Parallels Vesa driver question

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Tue, Aug 4, 2009 at 12:25 AM, Bakul Shah
<bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com>
> wrote:

> On Mon, 03 Aug 2009 20:12:08 PDT David Leimbach <leimy2k@gmail.com>
>  wrote:
> > Wow....  Where's parallels 4.  I doubt I qualify for a free one.  And
> VMWare
> > Fusion really sucks with Plan 9 at the moment :-(
>
> qemu works well enough for me on FreeBSD & Linux but not on a
> Mac.  VirtualBox doesn't run plan9 but it runs FreeBSD, Linux
> and Windows fairly well so may be there is hope.  There is an
> open source version of VirtualBox that might be worth
> tinkering with.
>
> I was considering giving qemu a try on the mac. I believe there's a mac
centric front-end for it even.
In fact, how much of virtualbox is using qemu?

[-- Attachment #2: Type: text/html, Size: 1097 bytes --]

Re: [9fans] Parallels Vesa driver question

[Bakul Shah]

On Tue, 04 Aug 2009 05:47:25 PDT David Leimbach <leimy2k@gmail.com>  wrote:
>
> On Tue, Aug 4, 2009 at 12:25 AM, Bakul Shah
> <bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com>
> > wrote:
>
> > On Mon, 03 Aug 2009 20:12:08 PDT David Leimbach <leimy2k@gmail.com>
> >  wrote:
> > > Wow....  Where's parallels 4.  I doubt I qualify for a free one.  And
> > VMWare
> > > Fusion really sucks with Plan 9 at the moment :-(
> >
> > qemu works well enough for me on FreeBSD & Linux but not on a
> > Mac.  VirtualBox doesn't run plan9 but it runs FreeBSD, Linux
> > and Windows fairly well so may be there is hope.  There is an
> > open source version of VirtualBox that might be worth
> > tinkering with.
> >
> > I was considering giving qemu a try on the mac. I believe there's a mac
> centric front-end for it even.

It's called Q. Don't bother.

> In fact, how much of virtualbox is using qemu?

I think vbox devices and recompiler are based on qemu but I
don't really know.  IIRC early qemu did seem to have similar
issues with plan9.

Since other OSes run pretty well, my guess is something plan9
depends on heavily has to be emulated (due to memory layout
assumptions or something).

Re: [9fans] Parallels Vesa driver question

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Tue, Aug 4, 2009 at 8:20 AM, Bakul Shah
<bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com>
> wrote:

> On Tue, 04 Aug 2009 05:47:25 PDT David Leimbach <leimy2k@gmail.com>
>  wrote:
> >
> > On Tue, Aug 4, 2009 at 12:25 AM, Bakul Shah
> > <bakul+plan9@bitblocks.com <bakul%2Bplan9@bitblocks.com><
> bakul%2Bplan9@bitblocks.com <bakul%252Bplan9@bitblocks.com>>
> > > wrote:
> >
> > > On Mon, 03 Aug 2009 20:12:08 PDT David Leimbach <leimy2k@gmail.com>
> > >  wrote:
> > > > Wow....  Where's parallels 4.  I doubt I qualify for a free one.  And
> > > VMWare
> > > > Fusion really sucks with Plan 9 at the moment :-(
> > >
> > > qemu works well enough for me on FreeBSD & Linux but not on a
> > > Mac.  VirtualBox doesn't run plan9 but it runs FreeBSD, Linux
> > > and Windows fairly well so may be there is hope.  There is an
> > > open source version of VirtualBox that might be worth
> > > tinkering with.
> > >
> > > I was considering giving qemu a try on the mac. I believe there's a mac
> > centric front-end for it even.
>
> It's called Q. Don't bother.
>
> > In fact, how much of virtualbox is using qemu?
>
> I think vbox devices and recompiler are based on qemu but I
> don't really know.  IIRC early qemu did seem to have similar
> issues with plan9.
>
> Since other OSes run pretty well, my guess is something plan9
> depends on heavily has to be emulated (due to memory layout
> assumptions or something).
>

I've also tried Minix and QNX and both have problems on Virtual Box.  Which
other OSes did you try?  Linux and windows work but they're like necessary
to even claim you can do anything virtualization wise.

Dave

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

Re: [9fans] Parallels Vesa driver question

[ron minnich]

On Tue, Aug 4, 2009 at 12:15 AM, Daniel Lyons<fusion@storytotell.org> wrote:

> I don't know how to obtain this information, but would be glad to supply it.
> Also, forgive my ignorance, but isn't there a chicken-and-egg problem, since
> if the MTRRs are set up in vgavesa.c, my display is unusable? Or is there a
> special way to bail out to the text mode when the display is screwed up?

Change the code to tell you what it would do to the mtrrs and then not
start up graphics but exit instead.

ron

Re: [9fans] Parallels Vesa driver question

[Bakul Shah]

On Tue, 04 Aug 2009 08:25:53 PDT David Leimbach <leimy2k@gmail.com>  wrote:
>
> On Tue, Aug 4, 2009 at 8:20 AM, Bakul Shah
> <bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com>
> > wrote:
	...
> > I think vbox devices and recompiler are based on qemu but I
> > don't really know.  IIRC early qemu did seem to have similar
> > issues with plan9.
> >
> > Since other OSes run pretty well, my guess is something plan9
> > depends on heavily has to be emulated (due to memory layout
> > assumptions or something).
> >
>
> I've also tried Minix and QNX and both have problems on Virtual Box.  Which
> other OSes did you try?  Linux and windows work but they're like necessary
> to even claim you can do anything virtualization wise.
>
> Dave

Just FreeBSD, linux and Windows.

Anyway, a couple of areas to look into, if you want plan9 on
vbox: try changing the memory layout of plan9 or figure out
what qemu did to make plan9 run well and apply that change to
vbox.

Re: [9fans] Parallels Vesa driver question

[erik quanstrom]

> Anyway, a couple of areas to look into, if you want plan9 on
> vbox: try changing the memory layout of plan9 or figure out
> what qemu did to make plan9 run well and apply that change to
> vbox.

what makes you think its a memory layout issue?

- erik

Re: [9fans] Parallels Vesa driver question

[Bakul Shah]

On Tue, 04 Aug 2009 13:46:31 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > Anyway, a couple of areas to look into, if you want plan9 on
> > vbox: try changing the memory layout of plan9 or figure out
> > what qemu did to make plan9 run well and apply that change to
> > vbox.
>
> what makes you think its a memory layout issue?

I can no longer remember but I think the following played some
part in thinking that.  Qemu internals document (on qemu.org):
    For system emulation, QEMU uses the mmap() system call to
    emulate the target CPU MMU. It works as long the emulated
    OS does not use an area reserved by the host OS (such as
    the area above 0xc0000000 on x86 Linux).
Elsewhere it says
    Achieving self-virtualization is not easy because there
    may be address space conflicts. QEMU solves this problem
    by being an executable ELF shared object as the
    ld-linux.so ELF interpreter. That way, it can be
    relocated at load time.
It was a hypothesis and it could be all wet.