search for: l2s

...ck the migration from being done. Naively we could do that if the guest has vmx or svm features in its CPU, except that's probably way too conservative as many guests with those features won't actually do any nested VMs. It would also be desirable to still be able to migrate the L1, if no L2s are running currently. Is there any way QEMU can expose whether there's any L2s activated to libvirt, so we can prevent migration in that case ? Or should QEMU itself refuse to start migration perhaps ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dbe...

.../x86/shadow.c --- a/xen/arch/x86/shadow.c Thu Jun 30 05:26:09 2005 +++ b/xen/arch/x86/shadow.c Thu Jun 30 05:26:24 2005 @@ -1906,7 +1906,7 @@ unsigned long gpfn, unsigned index) { unsigned long smfn = __shadow_status(d, gpfn, PGT_snapshot); - l1_pgentry_t *snapshot; // could be L1s or L2s or ... + l1_pgentry_t *snapshot, gpte; // could be L1s or L2s or ... int entries_match; perfc_incrc(snapshot_entry_matches_calls); @@ -1916,10 +1916,14 @@ snapshot = map_domain_page(smfn); + if (__copy_from_user(&gpte, &guest_pt[index], + s...

> Sure, I do understand that Red Hat (or any other vendor) is taking no > support responsibility for this. At this point I'd just like to > contribute to a better understanding of what's expected to definitely > _not_ work, so that people don't bloody their noses on that. :) Indeed. nesting is nice to enable as it works in 99% of all cases. It just doesn't work when

...readings), pause all L2 guests, update their kvmclock structures with new data (we already know the new TSC frequency) and then tell L0 that we're done and it can stop emulating TSC accesses. (Nothing like this exists for KVM-on-KVM, by the way, when L1's clocksource is 'kvmclock' L2s won't get a stable kvmclock clocksource.) -- Vitaly

...readings), pause all L2 guests, update their kvmclock structures with new data (we already know the new TSC frequency) and then tell L0 that we're done and it can stop emulating TSC accesses. (Nothing like this exists for KVM-on-KVM, by the way, when L1's clocksource is 'kvmclock' L2s won't get a stable kvmclock clocksource.) -- Vitaly

...guests, update their kvmclock > structures with new data (we already know the new TSC frequency) and > then tell L0 that we're done and it can stop emulating TSC accesses. > > (Nothing like this exists for KVM-on-KVM, by the way, when L1's > clocksource is 'kvmclock' L2s won't get a stable kvmclock clocksource.) > > -- > Vitaly

...and just fold the adjustment into the core timekeeping data? (Preferably the actual core data, which would require core changes, but it could plausibly be done in arch code, too.) > > (Nothing like this exists for KVM-on-KVM, by the way, when L1's > clocksource is 'kvmclock' L2s won't get a stable kvmclock clocksource.) > >

On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski wrote: > > > Hi Vitaly, Paolo, Radim, etc., > > > > > > On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner <tglx at linutronix.de>

On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski wrote: > > > Hi Vitaly, Paolo, Radim, etc., > > > > > > On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner <tglx at linutronix.de>

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking