[lkml]   [2007]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 23/25] [PATCH] paravirt hooks for arch initialization
Andi Kleen wrote:
>> -static void discover_ebda(void)
>> +void native_ebda_info(unsigned *addr, unsigned *size)
> I guess it would be better to use the resources frame work here.
> Before checking EBDA check if it is already reserved. Then lguest/Xen
> can reserve these areas and stop using it.

What's the EBDA actually used for? The only place which seems to use
ebda_addr is in the e820 code to avoid that area as RAM.

Seems to me that we can just arrange to have the early lguest/xen setup
code set the EBDA_ADDR pointer to NULL and make discover_ebda() special
case that to zero out ebda_addr/size.

>> +/* Overridden in paravirt.c if CONFIG_PARAVIRT */
>> +void __attribute__((weak)) memory_setup(void)
>> +{
>> + return setup_memory_region();
>> +}
>> +
>> +
>> void __init setup_arch(char **cmdline_p)
>> {
>> printk(KERN_INFO "Command line: %s\n", boot_command_line);
>> @@ -231,12 +255,19 @@ void __init setup_arch(char **cmdline_p)
>> saved_video_mode = SAVED_VIDEO_MODE;
>> bootloader_type = LOADER_TYPE;
>> + /*
>> + * By returning non-zero here, a paravirt impl can choose to
>> + * skip the rest of the setup process
>> + */
>> + if (paravirt_arch_setup())
>> + return;
> Sorry, but that's an extremly ugly and clumpsy interface and will lead
> to extensive code duplication in hypervisors because so much code
> is disabled.
> This needs to be solved in some better way.

Yeah, it seems a bit hamfisted. Looks like it would be better to deal
with it by some combination of:

1. implement pv analogues of existing functions
2. try to neutralize functions we don't care about in pv-land
3. refactoring the setup() function to make the pv-friendly and
pv-hostile parts clearly distinct

and remember: native isn't a special case; its just another pv driver.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-09 19:49    [W:0.252 / U:7.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site