All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Smetanin <asmetanin@virtuozzo.com>
To: Roman Kagan <rkagan@virtuozzo.com>,
	Peter Hornyack <peterhornyack@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Pavel Fedin <p.fedin@samsung.com>, kvm list <kvm@vger.kernel.org>,
	"Denis V. Lunev" <den@openvz.org>, Gleb Natapov <gleb@kernel.org>,
	<qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 5/5] kvm/x86: Hyper-V kvm exit
Date: Mon, 21 Dec 2015 15:59:49 +0300	[thread overview]
Message-ID: <5677F7C5.5040404@virtuozzo.com> (raw)
In-Reply-To: <20151218183911.GF3050@rkaganb.sw.ru>



On 12/18/2015 09:39 PM, Roman Kagan wrote:
> On Fri, Dec 18, 2015 at 10:10:11AM -0800, Peter Hornyack wrote:
>> On Fri, Dec 18, 2015 at 8:01 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> On 18/12/2015 16:19, Pavel Fedin wrote:
>>>> As far as i understand this code, KVM_EXIT_HYPERV is called when one
>>>> of three MSRs are accessed. But, shouldn't we have implemented
>>>> instead something more generic, like KVM_EXIT_REG_IO, which would
>>>> work similar to KVM_EXIT_PIO or KVM_EXIT_MMIO, but carry register
>>>> code and value?
>>>
>>> Yes, we considered that.  There were actually patches for this as well.
>>>   However, in this case the register is still emulated in the kernel, and
>>> userspace just gets informed of the new value.
>>
>> On brief inspection of Andrey's patch (I have not been following
>> closely) it looks like the kvm_hyperv_exit struct that's returned to
>> userspace contains more data (control, evt_page, and msg_page fields)
>> than simply the value of the MSR, so would the desired SynIC exit fit
>> into a general-purpose exit for MSR emulation?
>
> Frankly I'm struggling trying to recall why we implemented it this way.
> Actually all three fields are the values of respective MSRs and I don't
> see any necessity to pass all three at the same time when any of them
> gets updated.  The patch for QEMU adds an exit handler which processes
> the fields individually, so I have a strong suspicion that union was
> meant here rather than struct.
>
> I hope Andrey will help to shed some light on that when he's back in the
> office on Monday; meanwhile I think this peculiarity can be ignored.
Hello!

We have implemented Hyper-V related Vcpu exit not only for Hyper-V SynIC 
MSR's changes but also to provide future interface to transfer guest 
VMBus hypercalls parameters into QEMU.

Yes, we can use  KVM_EXIT_REG_IO/MSR_IO for Hyper-V SynIC MSRS's changes 
and can even use only one MSR value . So union inside struct 
kvm_hyperv_exit is excessive.

But we still need Vcpu exit to handle VMBus hypercalls by QEMU to 
emulate VMBus devices inside QEMU.

And currently we are going to extend struct kvm_hyperv_exit
to store Hyper-V VMBus hypercall parameters.

SynIC MSR's changes could be replaced by KVM_EXIT_REG_IO/MSR_IO
but could we replace Hyper-V VMBus hypercall and it's parameters
by KVM_EXIT_REG_IO/MSR_IO too?

>
> Roman.
>

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Smetanin <asmetanin@virtuozzo.com>
To: Roman Kagan <rkagan@virtuozzo.com>,
	Peter Hornyack <peterhornyack@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Pavel Fedin <p.fedin@samsung.com>, kvm list <kvm@vger.kernel.org>,
	"Denis V. Lunev" <den@openvz.org>, Gleb Natapov <gleb@kernel.org>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v4 5/5] kvm/x86: Hyper-V kvm exit
Date: Mon, 21 Dec 2015 15:59:49 +0300	[thread overview]
Message-ID: <5677F7C5.5040404@virtuozzo.com> (raw)
In-Reply-To: <20151218183911.GF3050@rkaganb.sw.ru>



On 12/18/2015 09:39 PM, Roman Kagan wrote:
> On Fri, Dec 18, 2015 at 10:10:11AM -0800, Peter Hornyack wrote:
>> On Fri, Dec 18, 2015 at 8:01 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> On 18/12/2015 16:19, Pavel Fedin wrote:
>>>> As far as i understand this code, KVM_EXIT_HYPERV is called when one
>>>> of three MSRs are accessed. But, shouldn't we have implemented
>>>> instead something more generic, like KVM_EXIT_REG_IO, which would
>>>> work similar to KVM_EXIT_PIO or KVM_EXIT_MMIO, but carry register
>>>> code and value?
>>>
>>> Yes, we considered that.  There were actually patches for this as well.
>>>   However, in this case the register is still emulated in the kernel, and
>>> userspace just gets informed of the new value.
>>
>> On brief inspection of Andrey's patch (I have not been following
>> closely) it looks like the kvm_hyperv_exit struct that's returned to
>> userspace contains more data (control, evt_page, and msg_page fields)
>> than simply the value of the MSR, so would the desired SynIC exit fit
>> into a general-purpose exit for MSR emulation?
>
> Frankly I'm struggling trying to recall why we implemented it this way.
> Actually all three fields are the values of respective MSRs and I don't
> see any necessity to pass all three at the same time when any of them
> gets updated.  The patch for QEMU adds an exit handler which processes
> the fields individually, so I have a strong suspicion that union was
> meant here rather than struct.
>
> I hope Andrey will help to shed some light on that when he's back in the
> office on Monday; meanwhile I think this peculiarity can be ignored.
Hello!

We have implemented Hyper-V related Vcpu exit not only for Hyper-V SynIC 
MSR's changes but also to provide future interface to transfer guest 
VMBus hypercalls parameters into QEMU.

Yes, we can use  KVM_EXIT_REG_IO/MSR_IO for Hyper-V SynIC MSRS's changes 
and can even use only one MSR value . So union inside struct 
kvm_hyperv_exit is excessive.

But we still need Vcpu exit to handle VMBus hypercalls by QEMU to 
emulate VMBus devices inside QEMU.

And currently we are going to extend struct kvm_hyperv_exit
to store Hyper-V VMBus hypercall parameters.

SynIC MSR's changes could be replaced by KVM_EXIT_REG_IO/MSR_IO
but could we replace Hyper-V VMBus hypercall and it's parameters
by KVM_EXIT_REG_IO/MSR_IO too?

>
> Roman.
>

  reply	other threads:[~2015-12-21 13:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10 12:36 [PATCH v4 0/5] KVM: Hyper-V synthetic interrupt controller Andrey Smetanin
2015-11-10 12:36 ` [Qemu-devel] " Andrey Smetanin
2015-11-10 12:36 ` [PATCH v4 1/5] kvm/irqchip: kvm_arch_irq_routing_update renaming split Andrey Smetanin
2015-11-10 12:36   ` [Qemu-devel] " Andrey Smetanin
2015-11-10 12:36 ` [PATCH v4 2/5] kvm/x86: split ioapic-handled and EOI exit bitmaps Andrey Smetanin
2015-11-10 12:36   ` [Qemu-devel] " Andrey Smetanin
2015-11-10 12:36 ` [PATCH v4 3/5] kvm/x86: per-vcpu apicv deactivation support Andrey Smetanin
2015-11-10 12:36   ` [Qemu-devel] " Andrey Smetanin
2015-11-10 12:36 ` [PATCH v4 4/5] kvm/x86: Hyper-V synthetic interrupt controller Andrey Smetanin
2015-11-10 12:36   ` [Qemu-devel] " Andrey Smetanin
2015-11-10 12:36 ` [PATCH v4 5/5] kvm/x86: Hyper-V kvm exit Andrey Smetanin
2015-11-10 12:36   ` [Qemu-devel] " Andrey Smetanin
2015-12-18 15:19   ` Pavel Fedin
2015-12-18 15:19     ` [Qemu-devel] " Pavel Fedin
2015-12-18 15:53     ` Denis V. Lunev
2015-12-18 15:53       ` [Qemu-devel] " Denis V. Lunev
2015-12-18 16:01     ` Paolo Bonzini
2015-12-18 16:01       ` [Qemu-devel] " Paolo Bonzini
2015-12-18 18:10       ` Peter Hornyack
2015-12-18 18:10         ` [Qemu-devel] " Peter Hornyack
2015-12-18 18:23         ` Paolo Bonzini
2015-12-18 18:23           ` [Qemu-devel] " Paolo Bonzini
2015-12-18 18:39         ` Roman Kagan
2015-12-18 18:39           ` [Qemu-devel] " Roman Kagan
2015-12-21 12:59           ` Andrey Smetanin [this message]
2015-12-21 12:59             ` Andrey Smetanin
2015-12-21 13:28             ` Pavel Fedin
2015-12-21 13:28               ` [Qemu-devel] " Pavel Fedin
2015-12-21 13:48               ` Andrey Smetanin
2015-12-21 13:48                 ` [Qemu-devel] " Andrey Smetanin
2015-12-21 15:21                 ` Pavel Fedin
2015-12-21 15:21                   ` [Qemu-devel] " Pavel Fedin
2015-12-18 18:25       ` 'Roman Kagan'
2015-12-18 18:25         ` [Qemu-devel] " 'Roman Kagan'
2015-12-21  7:44       ` Pavel Fedin
2015-12-21  7:44         ` [Qemu-devel] " Pavel Fedin
2015-12-18 18:00     ` 'Roman Kagan'
2015-12-18 18:00       ` [Qemu-devel] " 'Roman Kagan'

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5677F7C5.5040404@virtuozzo.com \
    --to=asmetanin@virtuozzo.com \
    --cc=den@openvz.org \
    --cc=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=p.fedin@samsung.com \
    --cc=pbonzini@redhat.com \
    --cc=peterhornyack@google.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkagan@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.