Thread (20 messages) 20 messages, 5 authors, 2016-11-01
STALE3501d
Revisions (9)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 [diff vs current]
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v1 [diff vs current]
  7. v1 [diff vs current]
  8. v1 current
  9. v3 [diff vs current]

[PATCH 0/3] Support userspace irqchip with arch timers

From: Alexander Graf <hidden>
Date: 2016-10-29 18:55:11
Also in: kvm, kvmarm

On 29 Oct 2016, at 15:19, Paolo Bonzini [off-list ref] wrote:
quoted
quoted
quoted
quoted
What the status of userspace for this thing? Are QEMU patches being
posted and reviewed?
I didn't see a notification that the patches were merged. Are they in
Linus' tree yet? Then I can post enablement to qemu-devel.
I think you got it backward. I have no intention of merging them until I
see a vague consensus on the userspace API, and a set of patches ready
to be merged in QEMU.
That's not how kvm apis are made.
Actually I think it's always been like this, depending on what Marc meant for
"ready to be merged in QEMU".  It doesn't make sense to merge KVM APIs without
having userspace patches at least posted as RFC to qemu-devel, and without
having at least a positive response from the QEMU architecture maintainer.
I halfway agree. I do agree that there needs to be a reference implementation that proves the API to make sense. That bit is referenced in the cover letter of the patch set.

Peter as the QEMU architecture maintainer has been part of the review process and involved from the beginning. In fact, the current approach was his idea.

Do we need to fly the loop over qemu-devel? I doubt it, but if it makes you happy I can post an RFC there too.
ARM does require a bit more care because there's no overlap between kernel
and userspace maintainers, so perhaps that's the source of the confusion?

Now, of course merging the patches in QEMU may take a month or two depending
on the timing (because you have to wait for the patches to be merged into
Linus's tree and for the KVM headers to be updated in QEMU---which is not
going to happen during freeze of course).  So of course the KVM patch thus
can be committed even if QEMU is in freeze, as long as the QEMU architecture
maintainer gives an overall green light.
Right. My plan was to make sure that people agree on the KVM interface. Then directly send non-RFC patches to qemu-devel, which can only happen when the KVM patches are merged. I didn?t see any reason why that approach would be controversial, since everyone who really cared was involved.

But again, I don?t care strongly enough to make a fuss. If people are happier with RFC patches on the ML rather than a github link to RFC patches, I?ll send them.


Alex
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help