Zachary Amsden wrote:
Avi Kivity wrote:
We haven't seen any issue with the 2.6.22 boot decompressor. Which
of the four (fs, gs, ldt, or tr) were proving problematic and why?
It was tr that was affecting Workstation, since we boot through normal
BIOS path, and only a 16-bit task was loaded
Avi Kivity wrote:
We haven't seen any issue with the 2.6.22 boot decompressor. Which of
the four (fs, gs, ldt, or tr) were proving problematic and why?
It was tr that was affecting Workstation, since we boot through normal
BIOS path, and only a 16-bit task was loaded at this point.
Just t
Zachary Amsden wrote:
Since I was just involved in the boot decompressor for another bug, I
took a look at this. 2.6.22 switches it to be 64-bit code. VT is
very picky about what state it can run in. Not using VT on Intel
64-bit hardware cripples performance, running at far below normal
s
> 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.
It belongs to the firmware.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-
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 us
Steven Rostedt wrote:
> --
> On Thu, 9 Aug 2007, Andi Kleen wrote:
>
>>> This has to match the normal C calling convention though, doesn't it?
>>>
>> Native cli/sti/save/restore_flags are all only assembly and can be easily
>> (in fact more easily than in C) written as pure assembler func
--
On Thu, 9 Aug 2007, Andi Kleen wrote:
>
> > This has to match the normal C calling convention though, doesn't it?
>
> Native cli/sti/save/restore_flags are all only assembly and can be easily
> (in fact more easily than in C) written as pure assembler functions. Then
> you can use whatever calli
> This has to match the normal C calling convention though, doesn't it?
Native cli/sti/save/restore_flags are all only assembly and can be easily
(in fact more easily than in C) written as pure assembler functions. Then
you can use whatever calling convention you want.
While some paravirt implem
> Hm. So x86-64 doesn't make 64-bit pointers be 64-bit aligned?
The ABI does of course, although the penalty of not doing it on current
CPUs is only minor.
-Andi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.l
--
On Wed, 8 Aug 2007, Jeremy Fitzhardinge wrote:
>
> At the moment Xen can't support guests with 2M pages. In 32-bit this
> isn't a huge problem, since the kernel doesn't assume it can map itself
> with 2M pages. But I think the 64-bit kernel assumes 2M pages are
> always available for mapping
--
On Thu, 9 Aug 2007, Jes Sorensen wrote:
> Stephen Rothwell wrote:
> > On Wed, 08 Aug 2007 20:32:15 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> > wrote:
> >> diff --git a/drivers/lguest/i386/lg.h b/drivers/lguest/i386/lg.h
> >> index 64f0abe..c5ea14c 100644
> >> --- a/drivers/lguest/i386/lg.h
>
--
On Thu, 9 Aug 2007, Jeremy Fitzhardinge wrote:
> Glauber de Oliveira Costa wrote:
> > On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> >>> Does it really matter?
> >>>
> >>>
> >> Well, yes, if alignment is an issue.
> >>
> > Of course, But the question rises from the context tha
Stephen Rothwell wrote:
On Wed, 08 Aug 2007 20:32:15 -0400 Steven Rostedt <[EMAIL PROTECTED]>
wrote:
diff --git a/drivers/lguest/i386/lg.h b/drivers/lguest/i386/lg.h
index 64f0abe..c5ea14c 100644
--- a/drivers/lguest/i386/lg.h
+++ b/drivers/lguest/i386/lg.h
@@ -20,6 +20,8 @@
#include
#include
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> Hi Steven,
>
> On Thu, 09 Aug 2007 00:36:31 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > Well, some may be merged with x86_64 later, but for now we move them
> > out of the way. Later on we can start seeing how we can combine
> > som
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> Hi Steven,
>
> I am just being pedantic here (and I should have beaten up on Rusty
> before now ... :-)
>
> On Thu, 09 Aug 2007 00:36:30 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > --- a/include/asm-i386/lg.h
> > +++ b/include/asm-i38
--
On Wed, 8 Aug 2007, Jeremy Fitzhardinge wrote:
> Steven Rostedt wrote:
> > /*
> > * x86 arch doesn't have an easy way to find out where
> > * gs is located. So we need to read the MSR. But first
> > * we need to save off the rcx, rax and rdx.
> >
> Why don't you store it in g
Glauber de Oliveira Costa wrote:
On 8/8/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
Add a generic lg.h file to call the architecture specific one.
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
new file mode 100644
index 000..4c4356e
--- /dev/null
+++ b/drivers/lguest/lg.h
@@ -0,0
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > +#ifdef CONFIG_PARAVIRT
> > +#include
> > +# ifdef CONFIG_X86_VSMP
> > +static inline int raw_irqs_disabled_flags(unsigned long flags)
> > +{
> > + return !(flags & X86_EFLAGS_IF) || (flags & X86_EFLAGS_AC);
> > +}
> > +# else
> > +stati
Glauber de Oliveira Costa wrote:
> On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>>> Does it really matter?
>>>
>>>
>> Well, yes, if alignment is an issue.
>>
> Of course, But the question rises from the context that they are both
> together at the beginning. So they ar
On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> > Does it really matter?
> >
>
> Well, yes, if alignment is an issue.
Of course, But the question rises from the context that they are both
together at the beginning. So they are not making anybody non-aligned.
Then the question: Why w
Glauber de Oliveira Costa wrote:
>>> +/*
>>> + * integers must be use with care here. They can break the
>>> PARAVIRT_PATCH(x)
>>> + * macro, that divides the offset in the structure by 8, to get a number
>>> + * associated with the hook. Dividing by four would be a solution, but it
>>> + * would
> > + case PARAVIRT_PATCH(make_pgd):
> > + case PARAVIRT_PATCH(pgd_val):
> > + case PARAVIRT_PATCH(make_pte):
> > + case PARAVIRT_PATCH(pte_val):
> > + case PARAVIRT_PATCH(make_pmd):
> > + case PARAVIRT_PATCH(pmd_val):
> > + case PARAVIRT_PATCH(make_pud):
> > + case
22 matches
Mail list logo
