On 11/30/21 13:04, Marc Zyngier wrote:
I have "queued" it, but that's just my queue - it's not on kernel.org
and it's not going to be in 5.16, at least not in the first batch.
There's plenty of time for me to rebase on top of a fix, if you want
to send the fix through your kvm-arm pull request. Just Cc me so
that I understand what's going on.
Since a month has passed and I didn't see anything related in the
KVM-ARM pull requests, I am going to queue this patch. Any conflicts
can be resolved through a kvmarm->kvm merge of either a topic branch
or a tag that is destined to 5.16.
Can you at least spell out *when* this will land?
It will be in kvm/next as soon as I finish running tests on it, which
may take a couple more days because I'm updating my machines to newer
operating systems.
There is, in general, a certain lack of clarity about what you are queuing,
where you are queuing it, and what release it targets.
Ok, thanks for the suggestion. Generally speaking:
- kvm/master is stuff that is merged and will be in the next -rc, right
now 5.16-rc4. It shouldn't ever rewind (though it may happen, it is rare)
- kvm/next is stuff that is merged and will be in the next merge window,
right now 5.17. It also shouldn't rewind.
- kvm/queue is stuff that the submitter shouldn't care about, and that
other people should only care about to check for conflicts. When I say
I "queued" a patch it goes in kvm/queue, and there's time to remove it
if something breaks.
Regarding this series:
- I am queuing it up to this patch
- I am queuing it to kvm/next, meaning it targets 5.17
- it looks like the next one (11/43) triggers a known AMD errata, so I'm
holding on the rest until we understand if it actually does, and if so
if AMD AVIC is doomed. For the time being, it will stay in kvm/queue.
Paolo
