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
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
by: Vitaly Kuznetsov
Reviewed-by: Michael Kelley
Signed-off-by: Roman Kagan
---
v3 -> v4:
- adjust the log message [Vitaly, Michael]
v2 -> v3:
- do not introduce x2apic-capable hv_apic accessors; leave original
x2apic accessors instead
v1 -> v2:
- add ifdefs to handle !CONFIG_X86_
On Thu, Oct 10, 2019 at 04:30:53PM +0900, Suleiman Souhlal wrote:
> This RFC is to try to solve the following problem:
>
> We have some applications that are currently running in their
> own namespace, that still talk to other processes on the
> machine, using IPC, and expect to run on the same ma
y EOI when
available; however, its implementation works for both xapic and x2apic
modes.
Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
Cc: sta...@vger.kernel.org
Suggested-by: Michael Kelley
Signed-off
On Wed, Oct 09, 2019 at 11:21:41AM +0200, Paolo Bonzini wrote:
> On 13/09/19 21:01, Suthikulpanit, Suravee wrote:
> > /*
> > +* In case APICv accelerate EOI write and do not trap,
> > +* in-kernel IOAPIC will not be able to receive the EOI.
> > +* In this case, we do lazy update of
On Fri, Oct 04, 2019 at 03:01:51AM +, Michael Kelley wrote:
> From: Roman Kagan Sent: Thursday, October 3, 2019 5:53
> AM
> > >
> > > AFAIU you're trying to mirror native_x2apic_icr_write() here but this is
> > > different from what hv_apic_icr_writ
On Thu, Oct 03, 2019 at 12:54:03PM +0200, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode
> > when supported by the vcpus.
> >
> > However, the apic access functions for Hyper-V enlighte
is in use.
Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
Cc: sta...@vger.kernel.org
Signed-off-by: Roman Kagan
---
v1 -> v2:
- add ifdefs to handle !CONFIG_X86_X2APIC
On Tue, Oct 01, 2019 at 06:44:08AM +0800, kbuild test robot wrote:
> url:
> https://github.com/0day-ci/linux/commits/Roman-Kagan/x86-hyperv-make-vapic-support-x2apic-mode/20191001-044238
> config: x86_64-randconfig-e004-201939 (attached as .config)
> compiler: gcc-7 (Debian 7.4
is in use.
Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
Cc: sta...@vger.kernel.org
Signed-off-by: Roman Kagan
---
arch/x86/hyperv/hv_apic.c | 48 ---
1 fil
p the condition around to avoid the conditional execution on i386.
>
> Signed-off-by: Arnd Bergmann
> ---
> v3: reword commit log, simplify patch again
> v2: make the change inside of is_64_bit_mode().
> ---
> arch/x86/kvm/hyperv.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
Reviewed-by: Roman Kagan
e compiler how the code is actually executed.
>
> Signed-off-by: Arnd Bergmann
> ---
> v2: make the change inside of is_64_bit_mode().
> ---
> arch/x86/kvm/hyperv.c | 6 ++
> arch/x86/kvm/x86.h| 4
> 2 files changed, 6 insertions(+), 4 deletions(-)
Reviewed-by:
On Fri, Jul 12, 2019 at 11:12:29AM +0200, Arnd Bergmann wrote:
> clang points out that running a 64-bit guest on a 32-bit host
> would lead to uninitialized variables:
>
> arch/x86/kvm/hyperv.c:1610:6: error: variable 'ingpa' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsom
-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Roman Kagan
)
> fails only when APIC is disabled (see APIC_DM_FIXED case in
> __apic_accept_irq()). Remove the redundant part.
>
> Suggested-by: Roman Kagan
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 36 +++-
> 1 file chang
uggested-by: Roman Kagan
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 5 +
> 1 file changed, 5 insertions(+)
Reviewed-by: Roman Kagan
On Tue, Dec 11, 2018 at 04:04:01PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Tue, Dec 11, 2018 at 02:28:14PM +0100, Vitaly Kuznetsov wrote:
> >> Roman Kagan writes:
> >>
> >> > On Mon, Dec 10, 2018 a
On Tue, Dec 11, 2018 at 02:28:14PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Mon, Dec 10, 2018 at 06:21:56PM +0100, Vitaly Kuznetsov wrote:
>
> >> +
> >> +Currently, the following list of CPUID leaves are returned:
> >&g
On Mon, Dec 10, 2018 at 06:21:56PM +0100, Vitaly Kuznetsov wrote:
> With every new Hyper-V Enlightenment we implement we're forced to add a
> KVM_CAP_HYPERV_* capability. While this approach works it is fairly
> inconvenient: the majority of the enlightenments we do have corresponding
> CPUID featu
APIC and kvm_apic_set_irq()
> fails only when APIC is disabled (see APIC_DM_FIXED case in
> __apic_accept_irq()). Remove the redundant part.
>
> Suggested-by: Roman Kagan
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 36 +++
On Mon, Dec 10, 2018 at 01:54:18PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
> > Just noticed that the patch seems to assume that "direct" timers are
> > allowed to use any vectors including 0-15. I guess this is incorrect,
> > and instead stimer_set_co
On Mon, Nov 26, 2018 at 04:47:31PM +0100, Vitaly Kuznetsov wrote:
> Turns out Hyper-V on KVM (as of 2016) will only use synthetic timers
> if direct mode is available. With direct mode we notify the guest by
> asserting APIC irq instead of sending a SynIC message.
>
> The implementation uses exist
On Mon, Nov 26, 2018 at 04:47:31PM +0100, Vitaly Kuznetsov wrote:
> @@ -379,6 +398,14 @@ void kvm_hv_synic_send_eoi(struct kvm_vcpu *vcpu, int
> vector)
> for (i = 0; i < ARRAY_SIZE(synic->sint); i++)
> if (synic_get_sint_vector(synic_read_sint(synic, i)) == vector)
>
On Mon, Dec 03, 2018 at 12:35:35AM +0100, Vitaly Kuznetsov wrote:
> Nadav Amit writes:
>
> [skip]
>
> >
> > Having said that, something else is sort of strange in the TLFS definitions,
> > I think (I really know little about this whole protocol). Look at the
> > following definitions from hyperv
On Fri, Nov 30, 2018 at 02:44:54PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Nov 30, 2018 at 01:15:11PM +0100, Vitaly Kuznetsov wrote:
> >> Without 'packed' compiler is free to add optimization paddings and re-order
> >> structu
On Fri, Nov 30, 2018 at 01:15:11PM +0100, Vitaly Kuznetsov wrote:
> Without 'packed' compiler is free to add optimization paddings and re-order
> structure fields for randomization/optimization. And structures from
> hyperv-tlfs.h are used for hypervisor-guest communication, we need to
> ultimately
On Wed, Nov 28, 2018 at 02:07:42PM +0100, Thomas Gleixner wrote:
> On Wed, 28 Nov 2018, Vitaly Kuznetsov wrote:
>
> > Nadav Amit writes:
> >
> > >
> > > On a different note: how come all of the hyper-v structs are not marked
> > > with the “packed" attribute?
> >
> > "packed" should not be need
On Tue, Nov 27, 2018 at 02:54:21PM +0100, Paolo Bonzini wrote:
> On 27/11/18 09:37, Roman Kagan wrote:
> > On Mon, Nov 26, 2018 at 05:44:24PM +0100, Paolo Bonzini wrote:
> >> On 26/11/18 16:47, Vitaly Kuznetsov wrote:
> >>> diff --git a/arch/x86/kvm/x86.c b/
On Tue, Nov 27, 2018 at 02:10:49PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
> > On Mon, Nov 26, 2018 at 04:47:29PM +0100, Vitaly Kuznetsov wrote:
> > I personally tend to prefer masks over bitfields, so I'd rather do the
> > consolidation in the opposite dire
vm/hyperv.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
Reviewed-by: Roman Kagan
On Mon, Nov 26, 2018 at 05:44:24PM +0100, Paolo Bonzini wrote:
> On 26/11/18 16:47, Vitaly Kuznetsov wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 5cd5647120f2..b21b5ceb8d26 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -2997,6 +2997,7 @@ int kv
6/kvm/trace.h | 10 +++---
> arch/x86/kvm/x86.c | 1 +
> include/uapi/linux/kvm.h | 1 +
> 4 files changed, 67 insertions(+), 12 deletions(-)
Reviewed-by: Roman Kagan
[ Sorry for having missed v1 ]
On Mon, Nov 26, 2018 at 04:47:29PM +0100, Vitaly Kuznetsov wrote:
> We implement Hyper-V SynIC and synthetic timers in KVM too so there's some
> room for code sharing.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/include/asm/hyperv-tlfs.h | 69
On Mon, Oct 01, 2018 at 03:54:26PM +, Roman Kagan wrote:
> On Mon, Oct 01, 2018 at 05:48:54PM +0200, Paolo Bonzini wrote:
> > On 27/09/2018 11:17, Vitaly Kuznetsov wrote:
> > > Roman Kagan writes:
> > >
> > >> On Wed, Sep 26, 2018 at 07:02:56PM +0200,
On Mon, Oct 01, 2018 at 05:48:54PM +0200, Paolo Bonzini wrote:
> On 27/09/2018 11:17, Vitaly Kuznetsov wrote:
> > Roman Kagan writes:
> >
> >> On Wed, Sep 26, 2018 at 07:02:56PM +0200, Vitaly Kuznetsov wrote:
> >>> In most common cases VP index of a vc
On Wed, Sep 26, 2018 at 07:02:59PM +0200, Vitaly Kuznetsov wrote:
> Using hypercall for sending IPIs is faster because this allows to specify
> any number of vCPUs (even > 64 with sparse CPU set), the whole procedure
> will take only one VMEXIT.
>
> Current Hyper-V TLFS (v5.0b) claims that HvCallS
On Wed, Sep 26, 2018 at 07:02:58PM +0200, Vitaly Kuznetsov wrote:
> VP inedx almost always matches VCPU and when it does it's faster to walk
> the sparse set instead of all vcpus.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 96 +++
>
+++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Reviewed-by: Roman Kagan
tting vp_index = vcpu_idx.
> + */
> + if (hv_vcpu->vp_index == vcpu_idx)
> + atomic_inc(&hv->num_mismatched_vp_indexes);
> + else if (new_vp_index == vcpu_idx)
> + atomic_dec(&hv->num_mismatched_vp_indexes);
> +
> + hv_vcpu->vp_index = new_vp_index;
> break;
> + }
> case HV_X64_MSR_VP_ASSIST_PAGE: {
> u64 gfn;
> unsigned long addr;
Reviewed-by: Roman Kagan
v
> ---
> arch/x86/kvm/hyperv.c | 18 +-----
> 1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Roman Kagan
On Tue, Sep 25, 2018 at 11:29:57AM +0200, Paolo Bonzini wrote:
> On 25/09/2018 10:57, Roman Kagan wrote:
> > If we can assume that in all relevant cases vp_index coincides with the
> > cpu index (which I think we can) then Vitaly's approach is the most
> > efficient.
&g
On Mon, Sep 24, 2018 at 06:55:28PM +0200, Paolo Bonzini wrote:
> On 24/09/2018 18:24, Paolo Bonzini wrote:
> > Hi Paolo,
> >
> > could you please clarify what needs to be done to get this merged? In
> > particular, are you OK with my comment above or do we need to do
> > something with it (e.g. ge
*vcpu =
> + get_vcpu_by_vpidx(kvm, vp_index);
> +
> + /* Unknown vCPU specified */
> + if (!vcpu)
> + continue;
> +
> + /* We fail only when APIC is disabled */
> + kvm_apic_set_irq(vcpu, &irq, NULL);
> + }
> + }
> +
> +ret_success:
> + return HV_STATUS_SUCCESS;
> +}
> +
I still think that splitting kvm_hv_send_ipi into three functions would
make it more readable, but that's a matter of taste of course, so I'm OK
if Radim insists otherwise.
Reviewed-by: Roman Kagan
On Wed, Aug 22, 2018 at 12:18:32PM +0200, Vitaly Kuznetsov wrote:
> Using hypercall for sending IPIs is faster because this allows to specify
> any number of vCPUs (even > 64 with sparse CPU set), the whole procedure
> will take only one VMEXIT.
>
> Current Hyper-V TLFS (v5.0b) claims that HvCallS
---
> arch/x86/include/asm/hyperv-tlfs.h | 16 +---
> 2 files changed, 15 insertions(+), 13 deletions(-)
Reviewed-by: Roman Kagan
().
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 78
> ---
> 1 file changed, 31 insertions(+), 47 deletions(-)
Reviewed-by: Roman Kagan
netsov
> ---
> arch/x86/kvm/hyperv.c | 42 +++---
> virt/kvm/kvm_main.c | 6 ++
> 2 files changed, 25 insertions(+), 23 deletions(-)
Reviewed-by: Roman Kagan
early when supplied vpidx is >= KVM_MAX_VCPUS.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kvm/hyperv.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Reviewed-by: Roman Kagan
On Fri, Jun 29, 2018 at 07:26:36PM +0300, Roman Kagan wrote:
> On Fri, Jun 29, 2018 at 05:21:47PM +0200, Vitaly Kuznetsov wrote:
> > Roman Kagan writes:
> >
> > > On Fri, Jun 29, 2018 at 04:14:53PM +0200, Vitaly Kuznetsov wrote:
> > >> VP_INDEX almost always m
On Fri, Jun 29, 2018 at 05:21:47PM +0200, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Jun 29, 2018 at 04:14:53PM +0200, Vitaly Kuznetsov wrote:
> >> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
> >> use it instead of traver
On Fri, Jun 29, 2018 at 05:25:56PM +0200, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Jun 29, 2018 at 03:10:14PM +0200, Vitaly Kuznetsov wrote:
> >> Roman Kagan writes:
> >>
> >> > On Fri, Jun 29, 2018 at 01:37:44PM +0200, Vitaly
On Fri, Jun 29, 2018 at 04:14:53PM +0200, Vitaly Kuznetsov wrote:
> VP_INDEX almost always matches VCPU id and get_vcpu_by_vpidx() is fast,
> use it instead of traversing full vCPU list every time.
>
> To support the change switch kvm_make_vcpus_request_mask() to checking
> vcpu_id instead of vcpu
On Fri, Jun 29, 2018 at 03:10:14PM +0200, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Jun 29, 2018 at 01:37:44PM +0200, Vitaly Kuznetsov wrote:
> >> The problem we're trying to solve here is: with PV TLB flush and IPI we
> >> need to walk thro
On Fri, Jun 29, 2018 at 01:37:44PM +0200, Vitaly Kuznetsov wrote:
> The problem we're trying to solve here is: with PV TLB flush and IPI we
> need to walk through the supplied list of VP_INDEXes and get VCPU
> ids. Usually they match. But in case they don't [...]
Why wouldn't they *in practice*?
On Fri, Jun 29, 2018 at 12:26:23PM +0200, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Thu, Jun 28, 2018 at 03:53:10PM +0200, Vitaly Kuznetsov wrote:
> >> While it is easy to get VP index from vCPU index the reverse task is hard.
> >> Basically, to solv
On Thu, Jun 28, 2018 at 03:53:10PM +0200, Vitaly Kuznetsov wrote:
> While it is easy to get VP index from vCPU index the reverse task is hard.
> Basically, to solve it we have to walk all vCPUs checking if their VP index
> matches. For hypercalls like HvFlushVirtualAddress{List,Space}* and the
> up
to remove an id >= 64.
> >
> > Fixes: 0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
> > Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
> > Debugged-by: Roman Kagan
> > Signed-off-by: Matthew Wilcox
>
> Neither of the cha
On Thu, May 10, 2018 at 10:16:34PM +0300, Roman Kagan wrote:
> If an IDR contains a single entry at index==0, the underlying radix tree
> has a single item in its root node, in which case
> __radix_tree_lookup(index!=0) doesn't set its *@nodep argument (in
> addition
On Fri, May 18, 2018 at 10:50:25AM -0700, Matthew Wilcox wrote:
> It'd be nice if you cc'd the person who wrote the code you're patching.
> You'd get a response a lot quicker than waiting until I happened to
> notice the email in a different forum.
I sent it to someone called "Matthew Wilcox ".
Al
On Fri, May 11, 2018 at 07:40:26AM +0200, Dmitry Vyukov wrote:
> On Fri, May 11, 2018 at 1:54 AM, Paolo Bonzini wrote:
> > On 10/05/2018 21:16, Roman Kagan wrote:
> >> If an IDR contains a single entry at index==0, the underlying radix tree
> >> has a single item in i
x27;t have
IDR_FREE tag.
As a result, on an attempt to remove an index!=0 entry from such an IDR,
radix_tree_delete_item doesn't return early and calls
__radix_tree_delete with invalid parameters which are then dereferenced.
Reported-by: syzbot+35666cba7f0a337e2...@syzkaller.appspotmail.com
Signe
cu_read_lock/unlock; the result is still protected by
> vcpu->kvm->srcu.
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/hyperv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Roman Kagan
On Mon, May 07, 2018 at 07:19:04PM +0200, Paolo Bonzini wrote:
> On 29/04/2018 19:00, syzbot wrote:
> > syzbot hit the following crash on upstream commit
> > bf8f5de17442bba5f811e7e724980730e079ee11 (Sat Apr 28 17:05:04 2018 +)
> > MAINTAINERS: add myself as maintainer of AFFS
> > syzbot dashbo
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 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
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
> arch/x86/kvm/x86.c | 12 +++-
> 3 files changed, 36 insertions(+), 1 deletion(-)
Reviewed-by: Roman Kagan
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:
> >
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
> ---
> 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 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 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 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 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
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
[ Sorry for such a slow reply; flu and office relocation knocked me out
for a while ]
On Wed, Dec 21, 2016 at 06:00:17PM +, KY Srinivasan wrote:
> > -Original Message-
> > From: Roman Kagan [mailto:rka...@virtuozzo.com]
> > Sent: Tuesday, December 20, 2016 7:56 AM
&
On Wed, Dec 21, 2016 at 07:54:11PM +, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > Sent: Wednesday, December 21, 2016 10:03 AM
> > To: Christoph Hellwig
> > Cc: Paolo Bonzini ;
On Wed, Dec 21, 2016 at 04:18:58AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 09:29:39AM +0300, Roman Kagan wrote:
> > QEMU in particular. We're planning to implement VMBus devices in QEMU
> > and would like to have the definitions shared with the Linux guest
&
On Wed, Dec 21, 2016 at 06:26:54AM -0800, Christoph Hellwig wrote:
> On Wed, Dec 21, 2016 at 03:59:20PM +0300, Roman Kagan wrote:
> > That's fine by me.
> >
> > I guess the series should then start with a complete move
> > arch/x86/include/uapi/asm/hype
On Wed, Dec 21, 2016 at 01:00:44PM +0100, Olaf Hering wrote:
> On Tue, Dec 20, Roman Kagan wrote:
>
> Reverting commit 22356585712d ("staging: hv: use sync_bitops when
> interacting with the hypervisor") is save because ...
>
> > - sy
On Tue, Dec 20, 2016 at 09:24:53AM -0800, Stephen Hemminger wrote:
> On Tue, 20 Dec 2016 18:55:49 +0300
> Roman Kagan wrote:
>
> > Move definitions related to the Hyper-V SynIC event flags to a header
> > where they can be consumed by userspace.
> >
> > While
On Tue, Dec 20, 2016 at 09:25:43AM -0800, Stephen Hemminger wrote:
> On Tue, 20 Dec 2016 18:55:59 +0300
> Roman Kagan wrote:
>
> > Userspace will need them too.
> >
> > Signed-off-by: Roman Kagan
>
> What userspace? I am worried about creating more stable API
On Tue, Dec 20, 2016 at 08:57:28PM +, KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Roman Kagan [mailto:rka...@virtuozzo.com]
> > Sent: Tuesday, December 20, 2016 7:56 AM
> > To: Paolo Bonzini ; Radim Krčmář
> > ; KY Srinivasan ;
Consolidate the guest-side and kvm-side definitions for Hyper-V TSC
reference page.
While at this, rewrite read_hv_clock_tsc using the existing helpers.
Signed-off-by: Roman Kagan
---
arch/x86/include/asm/kvm_host.h| 2 +-
arch/x86/include/uapi/asm/hyperv.h | 4 +--
drivers/hv
Use the definitions already present in the uapi header throughout the
guest driver, too.
Signed-off-by: Roman Kagan
---
drivers/hv/hyperv_vmbus.h | 11 ---
drivers/hv/vmbus_drv.c| 6 +++---
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b
Expose structures used for PostMessage and SignalEvent hypercalls in a
uapi header. While doing so, simplify alignment handling and drop
unnecessary complications in the connectionid field.
Signed-off-by: Roman Kagan
---
arch/x86/include/uapi/asm/hyperv.h | 18 ++
drivers/hv
Give a name to the constant (1) already used in the code.
Signed-off-by: Roman Kagan
---
arch/x86/include/uapi/asm/hyperv.h | 2 ++
drivers/hv/connection.c| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include
Use the definitions already present in the uapi header. Besides, drop
all bitfields for the msr values and use bitwise operations instead.
Signed-off-by: Roman Kagan
---
drivers/hv/hyperv_vmbus.h | 88 ---
drivers/hv/hv.c | 150
Move structures for monitored notifications to the uapi header for
userspace to be able to consume. Also observe that hv_monitor_parameter
is by definition the same as hv_input_signal_event so use the latter and
nuke the former.
Signed-off-by: Roman Kagan
---
arch/x86/include/uapi/asm/hyperv.h
There's no need in GFP_ATOMIC when initializing the driver state.
While at this, also rely on free_page() to take null argument.
Signed-off-by: Roman Kagan
---
drivers/hv/hv.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/hv/h
Use the definitions already present in the uapi header throughout the
guest driver, too.
Signed-off-by: Roman Kagan
---
drivers/hv/hyperv_vmbus.h | 19 ---
drivers/hv/hv.c | 6 +++---
2 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/hv
Signed-off-by: Roman Kagan
---
drivers/hv/channel.c| 8 +++-
drivers/hv/connection.c | 9 +++--
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 5fb4c6d..f9df275 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv
Make hypercall and tsc page allocation similar to the rest of the
Hyper-V shared memory stuff instead of vmalloc-ing them.
Also perform cleanup unconditionally which is safe.
TODO: the skipping of free in case of a crash is probably no longer
necessary, too.
Signed-off-by: Roman Kagan
Move definitions related to the Hyper-V SynIC event flags to a header
where they can be consumed by userspace.
While doing so, also clean up their use by switching to standard bitops
and struct-based dereferencing. The latter is also done for message
pages.
Signed-off-by: Roman Kagan
---
arch
This brings more symmetry in the API.
The downside is that this changes the userspace-visible structure.
Hopefully no userspace code had a chance to use it yet.
Signed-off-by: Roman Kagan
---
arch/x86/include/uapi/asm/hyperv.h | 32 +---
drivers/hv/hyperv_vmbus.h
Signed-off-by: Roman Kagan
---
drivers/hv/hyperv_vmbus.h | 44
drivers/hv/hv.c | 39 +++
2 files changed, 39 insertions(+), 44 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv
Userspace will need them too.
Signed-off-by: Roman Kagan
---
arch/x86/include/uapi/asm/hyperv.h | 9 +
drivers/hv/hyperv_vmbus.h | 10 --
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include/uapi/asm
None of these is used in the kernel.
Signed-off-by: Roman Kagan
---
drivers/hv/hyperv_vmbus.h | 119 --
1 file changed, 119 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index fcb5d91..8ce6d64 100644
--- a/drivers/hv
1 - 100 of 133 matches
Mail list logo
