On Fri, Sep 02, 2016 at 06:37:59PM +0200, Paolo Bonzini wrote:
>
>
> On 02/09/2016 16:51, Roman Kagan wrote:
> > On Fri, Sep 02, 2016 at 04:09:42PM +0200, Paolo Bonzini wrote:
> >> On 02/09/2016 15:52, Roman Kagan wrote:
> >> vs. using a single offset as in t
t more compact by
removing unnecessary local variables.
Signed-off-by: Roman Kagan
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Paolo Bonzini
Cc: sta...@vger.kernel.org
---
arch/x86/include/asm/pvclock.
On Wed, Jun 08, 2016 at 09:45:09PM +0200, Borislav Petkov wrote:
> On Wed, Jun 08, 2016 at 09:11:39PM +0300, Roman Kagan wrote:
> > Gradual removal of excessive barriers in pvclock reading functions
> > (commits 502dfeff239e8313bfbe906ca0a1a6827ac8481b,
> > a3eb97bd80134ba0786
On Thu, Jun 09, 2016 at 12:01:13AM +0300, Roman Kagan wrote:
> On Wed, Jun 08, 2016 at 09:45:09PM +0200, Borislav Petkov wrote:
> > On Wed, Jun 08, 2016 at 09:11:39PM +0300, Roman Kagan wrote:
> > > --- a/arch/x86/include/asm/pvclock.h
> > > +++ b/arch/x86/include/as
't in Linus' tree yet so
I wonder if it makes sense to merge the two patches into one.
Will you post it to stable, too?
Anyway
Reviewed-by: Roman Kagan
Roman.
On Thu, Jun 09, 2016 at 02:47:54PM +0200, Paolo Bonzini wrote:
> On 09/06/2016 14:43, Roman Kagan wrote:
> > On Thu, Jun 09, 2016 at 01:23:23PM +0200, Paolo Bonzini wrote:
> >> The version field in struct pvclock_vcpu_time_info basically implements
> >> a seqcou
On Wed, Mar 09, 2016 at 02:38:52PM -0500, Rik van Riel wrote:
> On Wed, 2016-03-09 at 20:04 +0300, Roman Kagan wrote:
> > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote:
> > > > Fo
On Wed, Mar 09, 2016 at 07:39:18PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 09, 2016 at 08:04:39PM +0300, Roman Kagan wrote:
> > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote:
> &g
On Fri, Mar 04, 2016 at 06:51:21PM +, Dr. David Alan Gilbert wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
> >
> >
> > On 04/03/2016 15:26, Li, Liang Z wrote:
> > >> >
> > >> > The memory usage will keep increasing due to ever growing caches, etc,
> > >> > so
> > >> > you'll be left
On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote:
> On Mon, Mar 07, 2016 at 06:49:19AM +, Li, Liang Z wrote:
> > > > No. And it's exactly what I mean. The ballooned memory is still
> > > > processed during live migration without skipping. The live migration
> > > > code is
>
On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote:
> > For (1) I've been trying to make a point that skipping clean pages is
> > much more likely to result in noticable benefit than free pages onl
On Thu, Mar 03, 2016 at 06:44:24PM +0800, Liang Li wrote:
> The current QEMU live migration implementation mark the all the
> guest's RAM pages as dirtied in the ram bulk stage, all these pages
> will be processed and that takes quit a lot of CPU cycles.
>
> From guest's point of view, it doesn't
On Thu, Mar 03, 2016 at 05:46:15PM +, Dr. David Alan Gilbert wrote:
> * Liang Li (liang.z...@intel.com) wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these pages
> > will be processed and that takes quit a
On Fri, Mar 04, 2016 at 01:52:53AM +, Li, Liang Z wrote:
> > I wonder if it would be possible to avoid the kernel changes by parsing
> > /proc/self/pagemap - if that can be used to detect unmapped/zero mapped
> > pages in the guest ram, would it achieve the same result?
>
> Only detect the u
On Fri, Mar 04, 2016 at 08:23:09AM +, Li, Liang Z wrote:
> > On Thu, Mar 03, 2016 at 05:46:15PM +, Dr. David Alan Gilbert wrote:
> > > * Liang Li (liang.z...@intel.com) wrote:
> > > > The current QEMU live migration implementation mark the all the
> > > > guest's RAM pages as dirtied in the
On Fri, Mar 04, 2016 at 09:08:20AM +, Dr. David Alan Gilbert wrote:
> * Roman Kagan (rka...@virtuozzo.com) wrote:
> > On Fri, Mar 04, 2016 at 08:23:09AM +, Li, Liang Z wrote:
> > > The unmapped/zero mapped pages can be detected by parsing
> > > /proc/self/pagema
On Fri, Mar 04, 2016 at 09:08:44AM +, Li, Liang Z wrote:
> > On Fri, Mar 04, 2016 at 01:52:53AM +, Li, Liang Z wrote:
> > > > I wonder if it would be possible to avoid the kernel changes by
> > > > parsing /proc/self/pagemap - if that can be used to detect
> > > > unmapped/zero mapped pag
return 0;
> + return 0;
> + }
> + /* fall through */
I'd rather put it the other way around, with explicit error path and a
comment:
/* don't bother userspace if it has no way to handle it */
if (!vcpu_to_synic
secase where such regions actually kind of persist the
data -- across kexec.
Signed-off-by: Roman Kagan
---
drivers/nvdimm/e820.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvdimm/e820.c b/drivers/nvdimm/e820.c
index 4cd18be9d0e9..3af63b7b6d23 100644
--- a/drivers/nvdimm/e820.c
> ---
> arch/x86/include/uapi/asm/hyperv.h | 2 ++
> arch/x86/kvm/hyperv.c | 32 ++--
> 2 files changed, 24 insertions(+), 10 deletions(-)
Reviewed-by: Roman Kagan
On Wed, Feb 28, 2018 at 02:44:01PM +0100, Vitaly Kuznetsov wrote:
> Hyper-V 2016 on KVM with SynIC enabled doesn't boot with the following
> trace:
>
> kvm_entry:vcpu 0
> kvm_exit: reason MSR_WRITE rip 0xf8000131c1e5 info 0 0
> kvm_hv_synic_set_msr: vcpu_id
On Wed, Feb 28, 2018 at 04:35:59PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Wed, Feb 28, 2018 at 02:44:01PM +0100, Vitaly Kuznetsov wrote:
> >> Hyper-V 2016 on KVM with SynIC enabled doesn't boot with the following
> >> trace:
> >
> arch/x86/kvm/x86.c | 12 +++-
> 3 files changed, 36 insertions(+), 1 deletion(-)
Reviewed-by: Roman Kagan
16) or the Polling bit (bit 18) is set to 1, then they
> ignore the value of Vector. Make KVM act accordingly.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> Changes since v1:
> - Drop 'polling' bit check for now as we don't support this mode. We'll
> need t
On Wed, Mar 07, 2018 at 05:19:44PM +0100, Radim Krčmář wrote:
> 2018-02-26 18:11+0100, Vitaly Kuznetsov:
> > From: Ladi Prosek
> >
> > The assist page has been used only for the paravirtual EOI so far, hence
> > the "APIC" in the MSR name. Renaming to match the Hyper-V TLFS where it's
> > called
On Mon, Apr 02, 2018 at 06:10:54PM +0200, Vitaly Kuznetsov wrote:
> This is both a new feature and a bugfix.
>
> Bugfix description:
>
> It was found that Windows 2016 guests on KVM crash when they have > 64
> vCPUs, non-flat topology (>1 core/thread per socket; in case it has >64
> sockets Wind
On Fri, Dec 08, 2017 at 11:50:00AM +0100, Vitaly Kuznetsov wrote:
> When we run nested KVM on Hyper-V guests we need to update masterclocks for
> all guests when L1 migrates to a host with different TSC frequency.
> Implement the procedure in the following way:
> - Pause all guests.
> - Tell our ho
On Fri, Dec 08, 2017 at 11:49:57AM +0100, Vitaly Kuznetsov wrote:
> Hyper-V supports Live Migration notification. This is supposed to be used
> in conjunction with TSC emulation: when we are migrated to a host with
> different TSC frequency for some short period host emulates our accesses
> to TSC
On Mon, Dec 11, 2017 at 10:56:33AM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
> > On Fri, Dec 08, 2017 at 11:49:57AM +0100, Vitaly Kuznetsov wrote:
> >> +void register_hv_tsc_update(void (*cb)(void))
> >> +{
> >
> > The function name seems
On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote:
> On 28/12/2016 18:09, Roman Kagan wrote:
> > Am I correct assuming that QEMU is currently the only user of
> > arch/x86/include/uapi/asm/hyperv.h?
> >
> > Then I think we're fine withdrawing it
On Mon, Jan 09, 2017 at 12:40:48AM -0800, h...@zytor.com wrote:
> On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote:
> >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote:
> >> On 28/12/2016 18:09, Roman Kagan wrote:
> >> > Am I correct assuming that Q
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e211288b72f15259da86eed6eca680758dbe9e74
Gitweb:
https://git.kernel.org/tip/e211288b72f15259da86eed6eca680758dbe9e74
Author:Roman Kagan
AuthorDate:Thu, 10 Oct 2019 12:33:05
Committer
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: e211288b72f15259da86eed6eca680758dbe9e74
Gitweb:
https://git.kernel.org/tip/e211288b72f15259da86eed6eca680758dbe9e74
Author:Roman Kagan
AuthorDate:Thu, 10 Oct 2019 12:33:05
Committer
101 - 133 of 133 matches
Mail list logo
