Jeremy Fitzhardinge wrote:
>> Next question while looking at xen_load_gdt(): why does it use
>> multicalls in the first place? Seems that function puts only one
>> hypercall into the multicall array, so there is no obvious point in
>> using multicalls ...
>
> I think you're right; I probably converted it when I swept through and
> did the others without really thinking about the bootstrap consequences.
Well, after reading the code a bit more it seems the intention is to
call the function in a row with others, have stuff queued up (in case
lazy_mode == PARAVIRT_LAZY_CPU is set) and update everything in one go
then. I don't think that makes sense for that function as it isn't
performance-critical. It is called on boot and cpu bringup (well, not
yet) only, right?
We have a simliar issue for xen_write_gdt_entry() btw, it calls
mc_flush() which doesn't work too. I've fixed it that way:
@@ -761,7 +762,13 @@ static asmlinkage void __init xen_start_
/* set up PDA descriptor */
pack_descriptor(&low, &high, (unsigned)&boot_pda,
sizeof(boot_pda)-1,
0x80 | DESCTYPE_S | 0x02, 0);
+#if 0
xen_write_gdt_entry(cpu_gdt_table, GDT_ENTRY_PDA, low, high);
+#else
+ if (HYPERVISOR_update_descriptor(virt_to_machine(cpu_gdt_table +
GDT_ENTRY_PDA).maddr,
+ (u64)high << 32 | low))
+ BUG();
+#endif
/* set up %gs and init Xen parts of the PDA */
asm volatile("mov %0, %%gs" : : "r" (__KERNEL_PDA) : "memory");
[ gna, thunderbird isn't great for sending patches inline, you should
get the idea though ... ]
cheers,
Gerd
--
Gerd Hoffmann <kraxel at suse.de>
