On Mon, 2007-10-29 at 20:10 -0300, Glauber de Oliveira Costa wrote:
> From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
>
> tsc is very good time source (when it does not have drifts, does not
> change it's frequency, i.e. when it works), so it should have its rating
> raised to a value greater
On Tue, 2007-10-30 at 00:02 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > Not every guest support paravirt, but for correctness, all guests
> > require TSC, which must be exposed all the way up to userspace, no
> > matter what the ef
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
> if it's inaccurate why are you exposing it to the guest then? Native
> only uses the TSC if it's safe and accurate to do so.
Not every guest support paravirt, but fo
On Tue, 2007-10-30 at 10:02 -0200, Glauber de Oliveira Costa wrote:
> > No, if no paravirt clocksource is detected, nothing can override the
> > perfect TSC hardware clocksource rating of 400. And if a paravirt
> > clocksource is detected, it is always better than TSC.
>
> Why always? tsc is the
On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >
I understood it as reordering was permitted, but no re-orde
On Wed, 2007-11-21 at 09:13 +0200, Avi Kivity wrote:
> Where the device is implemented is an implementation detail that should
> be hidden from the guest, isn't that one of the strengths of
> virtualization? Two examples: a file-based block device implemented in
> qemu gives you fancy file for
Anthony Liguori wrote:
> Rusty Russell wrote:
>> On Mon, 2007-05-28 at 20:54 -0500, Anthony Liguori wrote:
>>
>>> Howdy,
>>>
>>> Does anyone know what the state of a pv_ops backend for KVM is? I
>>> know Ingo has an implementation that implements CR3 caching but I
>>> don't see any branches in
Nakajima, Jun wrote:
> And actually you don't need the write to CR3 to flush TLB because the
> one to CR4 does it. Or does kvm_flush_tlb_kernel assume that CR3 is
> updated at the same time?
>
> Jun
It should not be necessary, but I believe this was added as a workaround
to a PII erratum. I can'
Anthony Liguori wrote:
>
> I was thinking the same thing :-)
>
> I was actually thinking about adding a hypercall to set/clear a bit in
> a control register. The thought here is that it would be useful not
> just for the global bit but also for CR0.TS although we would need
> another paravirt_o
Avi Kivity wrote:
> Anthony Liguori wrote:
>>> For KVM, it should be okay as well. But we can replace two CR4 accesses
>>> with just one hypercall.
>>>
>>
>> I was thinking the same thing :-)
>>
>> I was actually thinking about adding a hypercall to set/clear a bit
>> in a c
Anthony Liguori wrote:
>
> I don't see a compelling reason to paravirtualize earlier although I
> also don't see a compelling reason not too. I noticed that VMI hooks
> setup.c. It wasn't immediately obvious why it was hooking there but
> perhaps it worthwhile to have a common hook? I suspect
Jeremy Fitzhardinge wrote:
> Well, I was suggesting we could print the banner later rather than
> forcing an earlier init.
>
> The important part is that you set your pv_ops before patching occurs,
> since that will bake the function calls into the rest of the kernel, and
> it will ignore any furth
Jeremy Fitzhardinge wrote:
> 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'
Anthony Liguori wrote:
> Zachary Amsden wrote:
>> Jeremy Fitzhardinge wrote:
>>> 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
Anthony Liguori wrote:
> Zachary Amsden wrote:
>> Anthony Liguori wrote:
>>> But what's the value in having it not in the kernel? Let's take Xen
>>> and lhype out of the picture because it clearly has to be there for
>>> them. You have a litt
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
Jeremy Fitzhardinge wrote:
>
> Hm, you need to quiesce the kernel in some way when you do a migrate,
> so making sure it isn't in a hypercall would be just part of that. In
> general you'd make sure all but one CPU is parked somewhere, and the
> remaining CPU is doing the suspend, right?
>
> Th
Jeremy Fitzhardinge wrote:
> 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 wh
Rusty Russell wrote:
> The main effect is to change the definition of "struct desc_struct" to
> a union of more complex types.
>
Yay! Someone finally killed it. Every time I tried to kill it, I ended
up off in the weeds chasing some bug.
>
> diff -r 656f3ff2c9ce arch/i386/kernel/process.c
Before, I was seeing times up to a minute or more to decompress a 1.3MB kernel
on a very fast box.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
===
--- a/arch/x86_64/boot/compressed/head.S
+++ a/arch/x86_64/boot/compresse
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
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> >> This patch refactors the current hypercall infrastructure to better
> >> support live
> >> migration and SMP. It eliminates the hypercall page by trapping the UD
> >> exce
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
> So then each module creates a hypercall page using this magic MSR and
> the hypervisor has to keep track of it so that it can appropriately
> change the page on migration. The page can only contain a single
> instruction or else it ca
On Tue, 2007-09-18 at 16:25 -0500, Ryan Harper wrote:
> * Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
> > noticed
> > > > that whenever we launch a VM within the gu
On Wed, 2007-09-19 at 10:08 -0500, Anthony Liguori wrote:
> Ryan Harper wrote:
> > * Avi Kivity <[EMAIL PROTECTED]> [2007-09-19 03:58]:
> >
> >> Ryan Harper wrote:
> >>
> We have a test which verifies #GP is not caused by setting the bits on
> either AMD or Intel chips. "Stray" b
Ingo Molnar wrote:
> * Zachary Amsden <[EMAIL PROTECTED]> wrote:
>
>
>> What you really want is more like
>> EXPORT_SYMBOL_READABLE_GPL(paravirt_ops);
>>
>
> yep. Not a big issue - what is important is to put the paravirt ops into
> the read-onl
Ingo Molnar wrote:
> i'm pleased to announce the first release of paravirtualized KVM (Linux
> under Linux), which includes support for the hardware cr3-cache feature
> of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
>
> the patch is against 2.6.20-rc3 + KVM trunk and can be
27 matches
Mail list logo
