er the text has been
> marked read-only: reference to early_gdt_descr causes a page fault.
>
> Update:
>
> It should be using pushsection/popsection.
>
Looks good, with one caveat below.
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> - .section .text
Laurent Vivier wrote:
> functionnalities:
>
> - allow to measure time spent by a CPU in a virtual CPU.
> - allow to display in /proc/state this value by CPU
> - allow to display in /proc//state this value by process
> - allow KVM to use these 3 previous functionnalities
>
So, currently time spe
Mathieu Desnoyers wrote:
> Xen i386 xen-head.S fix sections mixup
>
> xen-head.S does not come back to the data section, leaving the text section
> as current section. It causes problems with a slightly enhanced DEBUG_RODATA
> that supports CONFIG_HOTPLUG and bringing a CPU up after the text has be
Glauber de Oliveira Costa wrote:
> Thanks for the explanation, Andi. I understand it much better now, and
> agree with you.
>
> As alternatives what we have now, we can either keep the paravirt_ops
> as it is now for the native case, just hooking the vsmp functions in
> place of the normal one, (th
Glauber de Oliveira Costa wrote:
> This is hopefully the last iteration of the pvops64 patch.
>
> From the last version, we have only one change, which is
> include/asm-x86_64/processor.h: There were still one survivor in raw asm.
> Also, git screwed me up for some reason, and the 25th patch was m
Rusty Russell wrote:
> On Tue, 2007-08-14 at 05:29 +0200, Andi Kleen wrote:
>
>> On Tue, Aug 14, 2007 at 09:55:50AM +0900, Yoshimi Ichiyanagi wrote:
>>
>> How is this related to virtualization?
>>
>>
>>> The problem is, if you compile x86_64 kernel, the value of
>>> CONFIG_PHYSICAL_ALIGN w
Glauber de Oliveira Costa wrote:
> Indeed, as the EBDA_ADDR_POINTER is not aligned, this may work even
> better.
>
> It seems to me safe to assume that if we read zero on that line:
>
> ebda_addr = *(unsigned short *)__va(EBDA_ADDR_POINTER);
>
> We could just do ebda_size = 0 and go home happy, ski
Glauber de Oliveira Costa wrote:
> I think the idea you gave me earlier of using probe_kernel_address could
> work. Xen/lguest/put_yours_here that won't use an ebda would then have
> to unmap the page, to make sure a read would fault.
Hm, the memory might be mapped anyway, but we could make sure i
Glauber de Oliveira Costa wrote:
> On 8/9/07, Alan Cox <[EMAIL PROTECTED]> wrote:
>
>>> 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.
>>
>
> Wouldn't it be better,
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
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 t
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
Andi Kleen wrote:
>> +if (opfunc == NULL)
>> +/* If there's no function, patch it with a ud2a (BUG) */
>> +ret = paravirt_patch_insns(site, len, start_ud2a, end_ud2a);
>>
>
> This will actually give corrupted BUGs because you don't supply
> the full inline BUG heade
Glauber de Oliveira Costa wrote:
> +static unsigned native_patch(u8 type, u16 clobbers, void *insns, unsigned
> len)
> +{
> + const unsigned char *start, *end;
> + unsigned ret;
> +
> + switch(type) {
> +#define SITE(x) case PARAVIRT_PATCH(x): start = start_##x; end =
> end_##x;
Glauber de Oliveira Costa wrote:
> The interrupt initialization routine becomes native_init_IRQ and will
> be overriden later in case paravirt is on.
>
> The interrupt vector is made global, so paravirt guests can reference
> it in their initializations.
Why? And if so, wouldn't it be better to a
Andi Kleen wrote:
>> @@ -264,13 +270,64 @@ struct thread_struct {
>> set_fs(USER_DS);
>> \
>> } while(0)
>>
>> -#define get_debugreg(var, register) \
>> -__asm__("movq %%db" #register ", %0"
Rusty Russell wrote:
> On Thu, 2007-08-09 at 02:24 +0200, Andi Kleen wrote:
>
>> Not sure what's best. Ok using a normal export is easiest and not
>> that big an issue.
>>
>
> Yeah, there's also been talk of breaking up paravirt_ops into multiple
> structs by area, which would lead naturall
Glauber de Oliveira Costa wrote:
> On 8/8/07, Nakajima, Jun <[EMAIL PROTECTED]> wrote:
>
>> Glauber de Oliveira Costa wrote:
>>
>>> Hi folks,
>>>
>>> After some time away from it, and a big rebase as a consequence, here
>>>
>> is
>>
>>> the updated version of paravirt_ops for x8
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 gs? movq %gs:my_gs_base, %rax?
J
Rusty Russell wrote:
> How's this?
> ===
> Link lguest example launcher non-static
>
> S.Caglar Onur points out that many distributions don't ship a static
> zlib. Unfortunately the launcher currently maps virtual device memory
> where shared libraries want to go.
>
> The solution is to pre-scan t
Zachary Amsden wrote:
Well, I think they are pretty good, but for the init group of ops, it
seems it would be clearer conceptually to group pagetable setup with
the MMU hooks and time init with the time operations. Otherwise, the
init group gets very jumbled as we pull in new interfaces (APIC
Zachary Amsden wrote:
I though about it, but it gets really ugly. You need wrappers for all
the MMU ops in pvops generic code, which means either another layer of
wrappers or a bunch of CONFIG_DEBUG_PARAVIRT
Oh, yes, more wrappers please! We could do it at the paravirt_ops
level: set up you
Zachary Amsden wrote:
I'd rather keep it, even with bitrot - it was non-trivial to get
correct, and found many surprises in the code; most notably, it can
detect
1) PTE writes to pages not declared as page tables
2) Failure to allocate or de-allocate page tables using the
paravirt-ops API
3)
Rusty Russell wrote:
Yes, but jiffies is the lowest-rated clock (so PIT will get chosen). I
initially mugged clocksource_jiffies.rating, but that felt wrong: it's
currently not registered when this code runs so it's a simple
assignment, but if code order was to change it would have to be
Carsten Otte wrote:
The big difference here is that LinuxOnLinux does represent guest
virtual addressing in these mm structs where all other kernel based
VMMs do represent guest physical in the user address space. That
somewhat disqualifies LinuxOnLinux to share the commonality.
Whether or not
Peter Chubb wrote:
In a hosted VMM like LinuxOnLinux or UML, context switch time can be a
major problem (as mmap when repeated for each guest page frame takes a
long time). One solution is to allow the host kernel to keep a cache of
address space contexts, and switch between them in a single
ope
Andrew Morton wrote:
Jeremy, I'll duck these patches for now, sorry. Mainly on
i-already-have-enough-x86-stuff grounds.
That's fine. I think it breaks x86-64 at the moment anyway. And I
haven't got much feedback about it.
There's a bit of overlap between this work and git-newsetup, bu
Zachary Amsden wrote:
Do you have a sample bootsector that does this? I would very much
like to try booting it rather than writing a mock-up which may or may
not exhibit the same behavior. .iso, floppy images greatly would help.
The very good news is that I should be able to tell you exactly
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
You mean "is a real failure"? Or "is triggered by particular
instructions"? It seems profoundly bogus (as in, surely DOS or
something reads the framebuffer).
A real failure (although only triggered from some varia
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Yes. Is this a report of observed failure? And how would VMWare even
go about implementing this kind of misfeature? Maybe it fails with
particular instructions reading the framebuffer?
It supposedly is.
You mean "is a
H. Peter Anvin wrote:
I just got the following message on the syslinux mailing list:
2. On some platforms (vmware for example :), READING from the video memory
in the 32bit mode is impossible (causes an exeption). Taking in to account
that the scroll function in ilinux/arch/i386/boot/c
ggy.o,
which cleans things up even more, since the .S file can also
set the input and output_size symbols without further linker
script hackery; it also removes a complete linker script.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EM
Ask the hypervisor how much space it needs reserved, since 32-on-64
doesn't need any space, and it may change in future.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/xen/enlighten.c | 13 -
1 file changed, 12 insertions(+),
e the uncompressed kernel vmlinux itself; it would
only take small buildsystem changes to implement this.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL P
ome paravirtualized environments, but
inapproprate for others.
2. Check the hardware architecture, and dispatch to the appropriate
kernel entrypoint. If the bootloader doesn't set this, then we
simply do the normal boot sequence.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PRO
[ This patch depends on the cross-architecture ELF cleanup patch. ]
This series updates the boot protocol to 2.07 and uses it to implement
paravirtual booting. This allows the bootloader to tell the kernel
what kind of hardware/pseudo-hardware environment it's coming up under,
and the kernel can
ved MSR to set the page address.
Once the kernel has been relocated, we update some of the pointers
in the start_info to kernel virtual addresses, and then jump to
xen_start_kernel() to do the rest of the setup before calling
start_kernel() proper.
Signed-off-by: Jeremy Fitzhardin
two cases, we generate abstracted versions of the
object files which only contain the symbols we care about (generated
with objcopy --strip-all --keep-symbol=X), and then include those
symbol tables with ld -R.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederm
ned-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmlinux.lds.S|9 -
arch/i386/kernel/vsyscall-note.S |4 +---
include/asm-generic/vmlinux.lds.h |7 ++-
include/linux/elfnote.h |2 +-
4 files changed, 12 insertions(
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
---
include/linux/elf_boot.h | 15 +++
1 file changed, 15 insertions(+)
===
--- /dev/null
+++ b/include/linu
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/linkage.h |6 ++
1 file changed, 6 insertions(+)
===
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -34,6 +34,12 @@
name:
Anthony Liguori wrote:
The real trick is doing it without the guest being involved at all.
Right now, it won't be a problem in KVM since the hypercall page only
differs by a single instruction across platforms. In the future,
we'll have to be smarter and wait for all VCPUs to leave the hyperc
Zachary Amsden wrote:
If I had a gentoo install,
Yes, but then you'd be a gentoo user. ;)
I would probably go so far as to want to recompile everything after
migration across CPU vendors; things like NMIs, MSRs, thermal controls
and sleep states are also vendor dependent and either need to b
Zachary Amsden wrote:
Yes, but if we want to stay with that forward compatibility story, we
need a way to allow paravirt device probing to be completely
orthogonal to paravirt-ops probing. Either the VMware hypervisor
needs to NOT implement a CPUID leaf, keeping the same ROM based
detection,
Zachary Amsden wrote:
You only need to quiesce if you have guest-visible data-structures
that have details about the underlying hardware. So Xen needs to
quiesce, but I don't know of any other VMM that would.
VMI, KVM and lhype should be capable of transparent migration without
guest involve
Zachary Amsden wrote:
Unless you also migrate the hypercall page itself and impose migration
restrictions on compatible hypercall pages.
Seems unreasonable, especially if you support migration between VT and
SVM machines. The whole point of a hypercall page is to give you a
point of indirect
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you cann
Zachary Amsden wrote:
Basically, it just makes it easier on distributors and allows any old
kernel with paravirt-ops module support to run on any modern, new
hypervisor - that might not have even existed at the time the distro
was created.
Hey, isn't that what VMI's for? ;)
I'd been thinking
Zachary Amsden wrote:
For a VMM which supports both full emulation and para-virtualization,
testing CPUID leaves is not sufficient to determine applicability of a
paravirt device driver. This only indicates the presence of the
functionality, not the fact that the functionality has been
activa
Anthony Liguori wrote:
> I don't agree that having paravirt_ops within a normal module is all
> that useful. By the time modules can be loaded, the kernel has
> completely booted. There should only be a handful of paravirt_ops
> implementations and they aren't large so I don't think there's a big
Anthony Liguori wrote:
> Perhaps my grep'ing skills are weak, but I don't seem to see any.
> Were you thinking of something in particular?
__pte(), of course. Sheesh. ;)
J
___
Virtualization mailing list
Virtualization@lists.linux-foundation.or
Anthony Liguori wrote:
> I've updated this patch and switched to using a scale/shift like Xen
> is doing, but I must admit, I don't understand how it helps adjtime.
> I poked around a bit and it wasn't obvious.
>
> Why is having {mult=1<<22, shift=22} better for adjtime than {mult=1,
> shift=0}?
Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
>> Anthony Liguori wrote:
>>
>>> Okay. I may remove this patch from the patch series and attempt to
>>> sit down next week and work out something more complete that also
>>> implements stolen time
Anthony Liguori wrote:
> Okay. I may remove this patch from the patch series and attempt to
> sit down next week and work out something more complete that also
> implements stolen time accounting.
Well, that's a separate problem. clocksource.read should always return
real time passed, so stolen
Anthony Liguori wrote:
> +static cycle_t read_hyper(void)
> +{
> + struct timespec now;
> + int ret;
> +
> + ret = kvm_hypercall(KVM_HYPERCALL_GET_KTIME, (u32)&now, 0, 0, 0);
> + WARN_ON(ret);
> +
> + return now.tv_nsec + now.tv_sec * (cycles_t)1e9;
>
Hm, use of FP looks pre
Anthony Liguori wrote:
> Perhaps we can just print the banner before batching occurs? Then
> it's being printed at the last possible moment.
s/batching/patching/? Yes, that would work.
J
___
Virtualization mailing list
Virtualization@lists.linux-f
Anthony Liguori wrote:
> Hi Jeremy,
>
> Jeremy Fitzhardinge wrote:
>> Anthony Liguori wrote:
>>
>>> 1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
>>> sure which paravirt_ops calls are actually re-entrant.
>>>
&
Jeremy Fitzhardinge wrote:
>> +static int kvm_hypercall_flush(struct kvm_vcpu *vcpu)
>> +{
>> +struct kvm_hypercall_entry *queue;
>> +struct kvm_vmca *vmca;
>> +int ret = 0;
>> +int i;
>> +
>> +queue = kmap(vcpu->que
Anthony Liguori wrote:
> Regards,
>
> Anthony Liguori
>
>
> Subject: [PATCH] KVM: Add hypercall queue for paravirt_ops implementation
> Author: Anthony Liguori <[EMAIL PROTECTED]>
>
> Implemented a hypercall queue that can be
Anthony Liguori wrote:
> 1) Not really sure what is needed for CONFIG_PREEMPT support. I'm not
> sure which paravirt_ops calls are actually re-entrant.
I'm not sure that has specifically come up. The main issue is whether a
particular call can be preempted and whether that matters. I guess the
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>
>> H. Peter Anvin wrote:
>>
>>> Jeremy Fitzhardinge wrote:
>>>
>>>
>>>> -setup_move_size: .word 0x8000# size to move, when setup is
>>>> not
7;s not a lot of new code.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
diff -r 3af164753238 tools/libxc/Makefile
--- a/tools/libxc/Makefile Thu Jun 14 08:15:19 2007 -0700
+++ b/tools/libxc/Makefile Thu Jun 14 08:43:44 2007 -0700
@@ -47,6 +47,7 @@ GUEST_SRCS-y += $(LIB
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>
>> +#define EIN_PROGRAM_CHECKSUM3 /* ip style checksum of the memory
>> image. */
>>
>
> Why on earth use one of the weakest verificants in common use?
I don't know. I copied this stuff f
Satya wrote:
> hi,
> I was trying to figure out the boot code of mini-os included in the
> Xen-3.1 source distribution. Is it going to change significantly
> because of this new boot protocol? thanks!
No, there's no change for existing Xen kernels. It only changes if
you're booting from a bzImage
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>
>> -setup_move_size: .word 0x8000 # size to move, when setup is
>> not
>> +setup_move_size: .word _setup_size # size to move, when setup is not
>> # loaded
two cases, we generate abstracted versions of the
object files which only contain the symbols we care about (generated
with objcopy --strip-all --keep-symbol=X), and then include those
symbol tables with ld -R.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederm
ved MSR to set the page address.
Once the kernel has been relocated, we update some of the pointers
in the start_info to kernel virtual addresses, and then jump to
xen_start_kernel() to do the rest of the setup before calling
start_kernel() proper.
Signed-off-by: Jeremy Fitzhardin
Ask the hypervisor how much space it needs reserved, since 32-on-64
doesn't need any space, and it may change in future.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/xen/enlighten.c | 13 -
1 file changed, 12 insertions(+),
ned-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmlinux.lds.S|9 -
arch/i386/kernel/vsyscall-note.S |4 +---
include/asm-generic/vmlinux.lds.h |7 ++-
include/linux/elfnote.h | 21 ++---
4 files changed, 25 i
ome paravirtualized environments, but
inapproprate for others.
2. Check the hardware architecture, and dispatch to the appropriate
kernel entrypoint. If the bootloader doesn't set this, then we
simply do the normal boot sequence.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PRO
ggy.o,
which cleans things up even more, since the .S file can also
set the input and output_size symbols without further linker
script hackery; it also removes a complete linker script.
- Also, remove stray "sti"
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/elf.h | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
===
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -1,9
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/linkage.h |6 ++
1 file changed, 6 insertions(+)
===
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -34,6 +34,12 @@
name:
This series updates the boot protocol to 2.07 and uses it to implement
paravirtual booting. This allows the bootloader to tell the kernel
what kind of hardware/pseudo-hardware environment it's coming up under,
and the kernel can use the appropriate boot sequence code.
Specifically:
- Update the
e the uncompressed kernel vmlinux itself; it would
only take small buildsystem changes to implement this.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL P
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
---
include/linux/elf_boot.h | 15 +++
1 file changed, 15 insertions(+)
===
--- /dev/null
+++ b/include/linu
H. Peter Anvin wrote:
> It doesn't if we simply declare that a certain chunk of memory is
> available to it, for the case where it runs in the native configuration.
> Since it doesn't have to support *any* ELF file, just the kernel one,
> that's an option.
>
I suppose. But given that its alway
H. Peter Anvin wrote:
> I was thinking prescriptive, having the decompressor read the output
> stream and interpret it as ELF. I guess a descriptive approach could be
> made to work, too (I haven't really thought about that avenue of
> approach), but the prescriptive model seems more powerful, at
H. Peter Anvin wrote:
> I still believe that we should provide, in effect, vmlinux as a
> (compressed) ELF file rather than provide the intermediate stage. It
> would reduce the complexity of testing (all information provided about a
> stage have to be both guaranteed to even make sense in the fut
two cases, we generate abstracted versions of the
object files which only contain the symbols we care about (generated
with objcopy --strip-all --keep-symbol=X), and then include those
symbol tables with ld -R.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederm
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Vivek Goyal <[EMAIL PROTECTED]>
---
include/linux/elf_boot.h | 15 +++
1 file changed, 15 insertions(+)
===
--- /dev/null
+++ b/include/linu
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/elf.h | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
===
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -1,9
ome paravirtualized environments, but
inappropraite for others.
2. Check the hardware architecture, and dispatch to the appropriate
kernel entrypoint. If the bootloader doesn't set this, then we
simply do the normal boot sequence.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PRO
ggy.o,
which cleans things up even more, since the .S file can also
set the input and output_size symbols without further linker
script hackery; it also removes a complete linker script.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EM
if it wishes. This is not particularly well-defined yet; I just added
it with the hope that it keeps HPA happy.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: "Eric W. Biederman" <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Vivek Goyal <
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
include/linux/linkage.h |6 ++
1 file changed, 6 insertions(+)
===
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -34,6 +34,12 @@
name:
This series:
1. Updates the boot protocol to version 2.07
2. Clean up the existing build process, to get rid of tools/build and
make the linker do more heavy lifting
3. Make the bzImage payload an ELF file. The bootloader can extract
this as a naked ELF file by skipping over boot_params
Make sure everything is backed out if it fails.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/paravirt.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
===
--- a/arch/i386/
Somehow an smp_processor_id() survived the transition to passing the
cpu around.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Jan Beulich <[EMAIL PROTECTED]>
---
arch/i386/xen/time.c |2 +-
1 file changed, 1 insertion(+)
self. If its within this
range, it calls the iret critical section fixup, which adjusts the
stack to deal with any unrestored registers, and then shifts the
stack frame up to replace the previous invocation.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/a
Andi Kleen wrote:
>> I once had some code in there to do that, implemented in very boneheaded
>> way with a spinlock to protect the "last time returned" variable. I
>> expect there's a better way to implement it.
>>
>
> But any per CPU setup likely needs this to avoid non monotonicity
Yeah.
Jan Beulich wrote:
> Xen itself knows to deal with this (by using an error correction factor to
> slow down the local [TSC-based] clock), but for the kernel such a situation
> may be fatal: If clocksource->cycle_last was most recently set on a CPU
> with shadow->tsc_to_nsec_mul sufficiently differe
Jan Beulich wrote:
>> --- a/arch/i386/xen/time.c
>> +++ b/arch/i386/xen/time.c
>> @@ -105,17 +105,15 @@ static void get_runstate_snapshot(struct
>> preempt_enable();
>> }
>>
>> -static void setup_runstate_info(void)
>> +static void setup_runstate_info(int cpu)
>> {
>> struct vcpu_register
Jeremy Fitzhardinge wrote:
> In a virtual environment, device drivers such as legacy IDE will waste
> quite a lot of time probing for their devices which will never appear.
> This helper function allows a paravirt implementation to lay claim to
> the whole iomem and ioport space, there
IO resources.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
diff -r 83c67f9402b5 arch/i386/kernel/paravirt.c
--- a/arch/i386/kernel/paravirt.c Tue Jun 05 17:41:04 2007 -0700
+++ b/arch/i386/kernel/paravirt.c Tue Jun 05 18:17:2
A domU Xen environment has no non-virtual drivers, so make sure
they're all disabled at once. This noticeably speeds up boot time.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
diff -r c79da0042c7d arch/i386/xen/setup.c
--- a/arch
Andi Kleen wrote:
> Ah I assumed the hypervisor would just check IF in ring 1 too.
> It would certainly make this easier, but then the additional trap
> of setting it would be also somewhat expensive agreed.
>
Xen doesn't do that because, while it could track sti/cli (expensively),
iret and pop
Andi Kleen wrote:
> If you stay cli you don't need that. Why is it that it has to enable
> interrupts?
>
Bear in mind we're talking about running paravirt under Xen in ring 1.
The cli/sti instructions don't control the event mask, so they're
effectively expensive no-ops (they trap into the hy
Santos, Jose Renato G wrote:
> It seems that we will still need specific devices drivers
> for each different virtualization flavor. For example,
> we will still need to have a specific Xen netfront
> device that talks to a backend device in dom0, using
> page grants, and other Xen speci
401 - 500 of 973 matches
Mail list logo
