All of lore.kernel.org
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/4] ARM: KVM: on unhandled IO mem abort, route the call to the KVM MMIO bus
Date: Thu, 13 Nov 2014 12:20:12 +0100	[thread overview]
Message-ID: <20141113112012.GO19598@cbox> (raw)
In-Reply-To: <CADDJ2=PTM0fJ0RFfWdVQ1-471xqaJmj0vP1f5-pf57xOV5jgig@mail.gmail.com>

On Thu, Nov 13, 2014 at 12:45:42PM +0200, Nikolay Nikolaev wrote:

[...]

> >>
> >> Going through the vgic_handle_mmio we see that it will require large
> >> refactoring:
> >>  - there are 15 MMIO ranges for the vgic now - each should be
> >> registered as a separate device
> >>  - the handler of each range should be split into read and write
> >>  - all handlers take 'struct kvm_exit_mmio', and pass it to
> >> 'vgic_reg_access', 'mmio_data_read' and 'mmio_data_read'
> >>
> >> To sum up - if we do this refactoring of vgic's MMIO handling +
> >> kvm_io_bus_ API getting 'vcpu" argument we'll get a 'much' cleaner
> >> vgic code and as a bonus we'll get 'ioeventfd' capabilities.
> >>
> >> We have 3 questions:
> >>  - is the kvm_io_bus_ getting 'vcpu' argument acceptable for the other
> >> architectures too?
> >>  - is this huge vgic MMIO handling redesign acceptable/desired (it
> >> touches a lot of code)?
> >>  - is there a way that ioeventfd is accepted leaving vgic.c in it's
> >> current state?
> >>
> > Not sure how the latter question is relevant to this, but check with
> > Andre who recently looked at this as well and decided that for GICv3 the
> > only sane thing was to remove that comment for the gic.
> @Andre - what's your experience with the GICv3 and MMIO handling,
> anything specific?
> >
> > I don't recall the details of what you were trying to accomplish here
> > (it's been 8 months or so) but the surely the vgic handling code should
> > *somehow* be integrated into the handle_kernel_mmio (like Paolo
> > suggested), unless you come back and tell me that that would involve a
> > complete rewrite of the vgic code.
> I'm experimenting now - it's not exactly rewrite of whole vgic code,
> but it will touch a lot of it  - all MMIO access handlers and the
> supporting functions.
> We're ready to spend the effort. My question is  - is this acceptable?
> 
I certainly appreciate the offer to do this work, but it's hard to say
at this point if it is worth it.

What I was trying to say above is that Andre looked at this, and came to
the conclusion that it is not worth it.

Marc, what are your thoughts?

-Christoffer

WARNING: multiple messages have this Message-ID (diff)
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
Cc: Andre Przywara <andre.przywara@linaro.org>,
	Antonios Motakis <a.motakis@virtualopensystems.com>,
	kvmarm@lists.cs.columbia.edu,
	VirtualOpenSystems Technical Team <tech@virtualopensystems.com>,
	Alexander Graf <agraf@suse.de>,
	marc.zyngier@arm.com, Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Russell King <linux@arm.linux.org.uk>,
	"open list:KERNEL VIRTUAL MA..." <kvm@vger.kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/4] ARM: KVM: on unhandled IO mem abort, route the call to the KVM MMIO bus
Date: Thu, 13 Nov 2014 12:20:12 +0100	[thread overview]
Message-ID: <20141113112012.GO19598@cbox> (raw)
In-Reply-To: <CADDJ2=PTM0fJ0RFfWdVQ1-471xqaJmj0vP1f5-pf57xOV5jgig@mail.gmail.com>

On Thu, Nov 13, 2014 at 12:45:42PM +0200, Nikolay Nikolaev wrote:

[...]

> >>
> >> Going through the vgic_handle_mmio we see that it will require large
> >> refactoring:
> >>  - there are 15 MMIO ranges for the vgic now - each should be
> >> registered as a separate device
> >>  - the handler of each range should be split into read and write
> >>  - all handlers take 'struct kvm_exit_mmio', and pass it to
> >> 'vgic_reg_access', 'mmio_data_read' and 'mmio_data_read'
> >>
> >> To sum up - if we do this refactoring of vgic's MMIO handling +
> >> kvm_io_bus_ API getting 'vcpu" argument we'll get a 'much' cleaner
> >> vgic code and as a bonus we'll get 'ioeventfd' capabilities.
> >>
> >> We have 3 questions:
> >>  - is the kvm_io_bus_ getting 'vcpu' argument acceptable for the other
> >> architectures too?
> >>  - is this huge vgic MMIO handling redesign acceptable/desired (it
> >> touches a lot of code)?
> >>  - is there a way that ioeventfd is accepted leaving vgic.c in it's
> >> current state?
> >>
> > Not sure how the latter question is relevant to this, but check with
> > Andre who recently looked at this as well and decided that for GICv3 the
> > only sane thing was to remove that comment for the gic.
> @Andre - what's your experience with the GICv3 and MMIO handling,
> anything specific?
> >
> > I don't recall the details of what you were trying to accomplish here
> > (it's been 8 months or so) but the surely the vgic handling code should
> > *somehow* be integrated into the handle_kernel_mmio (like Paolo
> > suggested), unless you come back and tell me that that would involve a
> > complete rewrite of the vgic code.
> I'm experimenting now - it's not exactly rewrite of whole vgic code,
> but it will touch a lot of it  - all MMIO access handlers and the
> supporting functions.
> We're ready to spend the effort. My question is  - is this acceptable?
> 
I certainly appreciate the offer to do this work, but it's hard to say
at this point if it is worth it.

What I was trying to say above is that Andre looked at this, and came to
the conclusion that it is not worth it.

Marc, what are your thoughts?

-Christoffer

  reply	other threads:[~2014-11-13 11:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1394726249-1547-1-git-send-email-a.motakis@virtualopensystems.com>
2014-03-13 15:57 ` [RFC PATCH 1/4] ARM: KVM: on unhandled IO mem abort, route the call to the KVM MMIO bus Antonios Motakis
2014-03-13 15:57   ` Antonios Motakis
2014-03-28 19:09   ` Christoffer Dall
2014-03-28 19:09     ` Christoffer Dall
2014-03-29 17:34     ` Paolo Bonzini
2014-03-29 17:34       ` Paolo Bonzini
2014-11-10 15:09     ` Nikolay Nikolaev
2014-11-10 15:09       ` Nikolay Nikolaev
2014-11-10 16:27       ` Christoffer Dall
2014-11-10 16:27         ` Christoffer Dall
2014-11-13 10:45         ` Nikolay Nikolaev
2014-11-13 10:45           ` Nikolay Nikolaev
2014-11-13 11:20           ` Christoffer Dall [this message]
2014-11-13 11:20             ` Christoffer Dall
2014-11-13 11:20             ` Christoffer Dall
2014-11-13 11:20               ` Christoffer Dall
2014-11-13 11:37             ` Marc Zyngier
2014-11-13 11:37               ` Marc Zyngier
2014-11-13 11:52               ` Andre Przywara
2014-11-13 11:52                 ` Andre Przywara
2014-11-13 12:29                 ` Nikolay Nikolaev
2014-11-13 12:29                   ` Nikolay Nikolaev
2014-11-13 12:52                   ` Andre Przywara
2014-11-13 12:52                     ` Andre Przywara
2014-11-13 14:16           ` Eric Auger
2014-11-13 14:16             ` Eric Auger
2014-11-13 14:23             ` Eric Auger
2014-11-13 14:23               ` Eric Auger
2014-11-13 15:02               ` Nikolay Nikolaev
2014-11-13 15:13                 ` Christoffer Dall
2014-11-13 15:31                 ` Andre Przywara
2014-11-13 16:07                   ` Eric Auger
2014-03-13 15:57 ` [RFC PATCH 2/4] KVM: irqfd should depend on CONFIG_HAVE_KVM_IRQ_ROUTING Antonios Motakis
2014-03-13 15:57 ` [RFC PATCH 3/4] ARM: KVM: enable linking against eventfd Antonios Motakis
2014-03-13 15:57   ` Antonios Motakis
2014-03-13 15:57 ` [RFC PATCH 4/4] ARM: KVM: enable KVM_CAP_IOEVENTFD Antonios Motakis
2014-03-13 15:57   ` Antonios Motakis

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=20141113112012.GO19598@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.