Hi,
> I think a good interface would expose the EDID block directly instead
> of a prefered resolution and let Seabios forge the EDID. Qemu is also
> the "virtual monitor" after all...
> It is easier to have support code which generates the EDID block in
> qemu, than having it in SeaBIOS.
Indeed, makes sense.
cheers,
Gerd
Hi,
>> I was thinking more along the lines of having
>> etc/vga-prefered-{xres,yres} fw_cfg files, then generate a EDID block
>> with them so xorg can pick them up and use as default resolution?
>>
>
> The problem is that the bochs driver will become qemu specific if we do that.
Of course we'll need default backups in case the fw_cfg interface or the
config files in fw_cfg space are not present, not only for non-qemu use
cases but also old qemu versions.
We could also extent the bochs interface for that (which is maybe the
better option anyway).
cheers,
Gerd
Hi,
> Is it worth trying to support high resolutions in Xorg ? If yes, then
> we need to expose a valid EDID block. But what capabilities should the
> virtual monitor report ? (I mean max resolution, preferred resolution,
> should they be static, provided by configuration options, or
> dynamically chosen at run-time).
At runtime, read from qemu firmware config interface?
cheers,
Gerd
On Thu, Mar 15, 2012 at 10:33:01AM -0400, Igor Mammedov wrote:
>
>
> ----- Original Message -----
> > From: "Gleb Natapov" <gleb(a)redhat.com>
> > To: "Igor Mammedov" <imammedo(a)redhat.com>
> > Cc: "Kevin O'Connor" <kevin(a)koconnor.net>, "jan kiszka" <jan.kiszka(a)siemens.com>, seabios(a)seabios.org
> > Sent: Thursday, March 15, 2012 3:13:58 PM
> > Subject: Re: [SeaBIOS] [PATCH 3/3] Take in account hot(un)plugged cpus on reboot
> >
> > On Thu, Mar 15, 2012 at 10:08:17AM -0400, Igor Mammedov wrote:
> > > > Good point. You mean we need a list of apic ids of available cpus
> > > > right?
> > > > Can SeaBIOS build this list by reading apic id in
> > > > smp_ap_boot_code?
> > >
> > > I've looked at how tables are build. It seems that it's not hard
> > > and sufficient
> > > to build an equivalent temporary byte array of (un)available apic
> > > ids that
> > > corresponds to 0xaf00 bitmap at boot time, under following
> > > restriction:
> > > - apic id shall be in range [0..max_cpus)
> > Why this restriction? ap bootstrap code can grab array entry with
> > atomic
> > operation and store its apic id there.
> we need to know in advance how large array to allocate.
> and if apic id is to serve as index in this array and to correspond to
> appropriate bit in 0xaf00 bitmap.
>
> Why limiting apic id range to [0..max_cpus) is bad thing?
>
IIRC part of topology information is conveyed through apic ids, so you
cannot express some topology with limited apic ranges. That said
currently seabios assumes that apic ids are in this range so it would
not be a big dial to continue assuming it for now.
> >
> > > * this will allow to allocate array where apic id will serve
> > > as index,
> > > thus making it equvivalent to 0xaf00 bitmap.
> > > * and easily fill this array in smp_ap_boot_code without
> > > inventing
> > > and using mutexes/spinlocks in smp_ap_boot_code.
> > >
> > >
> > > This will require cooperation from qemu side. apic id could be
> > > checked
> > > somewhere in device_add command handler call chain or at cpu object
> > > creation
> > > time.
> > >
> > > Jan,
> > > What do you think about setting such restriction on apic id of
> > > cpus in
> > > qemu?
> > >
> > We do have such restriction currently. A couple of years ago I
> > removed
> > it from the kernel, but qemu and current bios code still has it.
> >
> > --
> > Gleb.
> >
--
Gleb.
On Thu, Mar 15, 2012 at 07:33:10PM +0900, Daniel Castro wrote:
> Kevin, I greatly appreciate your help. Sorry to bother you again.
>
> Could you please check the following sample code, I am sure I am doing
> something wrong, but I am on the right path:
It would help if you sent actual code samples. The details are
important.
> I have:
> struct xendrive_s * xd = conteiner_of(op->drive_g,...)
GET_GLOBAL(op->drive_g) -- as that is a memory access.
> struct blk_info * bi = GLOBALFLAT2GLOBAL($(GET_GLOBALFLAT(xd)->info);
I don't know what $ does.
> To test I do:
> dprintf(1,"DEBUG test xendrive %p and an int
> %d.\n",GET_GLOBALFLAT(xd),GET_GLOBALFLAT(GET_GLOBALFLAT(bi)->buffer_gref));
Neither "bi" nor "xd" is a non-stack memory access so they shouldn't
be wrapped. "bi->buffer_gref" is a memory access. So it should look
like dprintf("...", xd, GET_GLOBALFLAT(bi->buffer_gref)). (This is
assuming the pointer in buffer_gref was obtained via malloc_fseg.)
-Kevin
On Thu, Mar 15, 2012 at 10:39 PM, Julian Pidancet
<julian.pidancet(a)gmail.com> wrote:
> On Fri, Mar 9, 2012 at 2:08 AM, Guillem Jover <guillem(a)hadrons.org> wrote:
>> On Fri, 2012-03-09 at 00:02:55 +0000, Julian Pidancet wrote:
>>> Some instructions are not emulated correctly by x86emu when they
>>> are prefixed by the 0x66 opcode.
>>> I've identified problems in the emulation of these intructions: ret,
>>> enter, leave, iret and some forms of call.
>>>
>>> Most of the time, the problem is that these instructions should push or
>>> pop 32-bit values to/from the stack, instead of 16bit, when they are
>>> prefixed by the 0x66 special opcode.
>>>
>>> The SeaBIOS project aims to produce a complete legacy BIOS
>>> implementation as well as a VGA option ROM, entirely written in C and
>>> using the GCC compiler.
>>>
>>> In 16bit code produced by the GCC compiler, the 0x66 prefix is used
>>> almost everywhere. This patch is necessary to allow the SeaBIOS VGA
>>> option ROM to function with Xorg when using the vesa driver.
>>>
>>> v2: - Decrement BP instead of EBP in accordance with the Intel Manual
>>> - Assign EIP instead of IP when poping the return address from the
>>> stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret
>>> - When poping EFLAGS from the stack in iret in 32-bit operand size
>>> mode, apply some mask to preserve Read-only flags.
>>>
>>> Signed-off-by: Julian Pidancet <julian.pidancet(a)gmail.com>
>>
>> Looks good to me:
>>
>> Reviewed-by: Guillem Jover <guillem(a)hadrons.org>
>>
>> thanks,
>> guillem
>
> Anyone interested in this ? Is there a maintainer for x86emu ? The
> MAINTAINERS file in xorg-docs doesn't mention anything about it.
>
CCed: Adam Jackson
Adam, you seem to be the maintainer of the xorg vesa driver. I think
this patch is closely related. Would you mind taking a look at it ?
Thanks,
--
Julian
On Fri, 2012-03-09 at 00:02:55 +0000, Julian Pidancet wrote:
> Some instructions are not emulated correctly by x86emu when they
> are prefixed by the 0x66 opcode.
> I've identified problems in the emulation of these intructions: ret,
> enter, leave, iret and some forms of call.
>
> Most of the time, the problem is that these instructions should push or
> pop 32-bit values to/from the stack, instead of 16bit, when they are
> prefixed by the 0x66 special opcode.
>
> The SeaBIOS project aims to produce a complete legacy BIOS
> implementation as well as a VGA option ROM, entirely written in C and
> using the GCC compiler.
>
> In 16bit code produced by the GCC compiler, the 0x66 prefix is used
> almost everywhere. This patch is necessary to allow the SeaBIOS VGA
> option ROM to function with Xorg when using the vesa driver.
>
> v2: - Decrement BP instead of EBP in accordance with the Intel Manual
> - Assign EIP instead of IP when poping the return address from the
> stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret
> - When poping EFLAGS from the stack in iret in 32-bit operand size
> mode, apply some mask to preserve Read-only flags.
>
> Signed-off-by: Julian Pidancet <julian.pidancet(a)gmail.com>
Looks good to me:
Reviewed-by: Guillem Jover <guillem(a)hadrons.org>
thanks,
guillem
On Thu, Mar 15, 2012 at 10:08:17AM -0400, Igor Mammedov wrote:
> > Good point. You mean we need a list of apic ids of available cpus
> > right?
> > Can SeaBIOS build this list by reading apic id in smp_ap_boot_code?
>
> I've looked at how tables are build. It seems that it's not hard and sufficient
> to build an equivalent temporary byte array of (un)available apic ids that
> corresponds to 0xaf00 bitmap at boot time, under following restriction:
> - apic id shall be in range [0..max_cpus)
Why this restriction? ap bootstrap code can grab array entry with atomic
operation and store its apic id there.
> * this will allow to allocate array where apic id will serve as index,
> thus making it equvivalent to 0xaf00 bitmap.
> * and easily fill this array in smp_ap_boot_code without inventing
> and using mutexes/spinlocks in smp_ap_boot_code.
>
>
> This will require cooperation from qemu side. apic id could be checked
> somewhere in device_add command handler call chain or at cpu object creation
> time.
>
> Jan,
> What do you think about setting such restriction on apic id of cpus in
> qemu?
>
We do have such restriction currently. A couple of years ago I removed
it from the kernel, but qemu and current bios code still has it.
--
Gleb.
- Halt if number of started cpus are more then expected
- Allow bios to detect if qemu has cpus status map for acpi hotplug
- Take in account hot(un)plugged cpus on reboot
Related qemu patches I'll post to qemu-devel
Signed-off-by: Igor Mammedov <imammedo(a)redhat.com>
