On 09/04/2013 01:35 AM, Paolo Bonzini wrote: > Il 03/09/2013 17:28, Alexey Kardashevskiy ha scritto: >> On 09/03/2013 08:42 PM, Jan Kiszka wrote: >>> On 2013-09-03 11:32, Alexey Kardashevskiy wrote: >>>> On 09/03/2013 07:29 PM, Peter Maydell wrote: >>>>> On 3 September 2013 09:27, Alexey Kardashevskiy <aik@xxxxxxxxx> wrote: >>>>>> Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxxxx> >>>>>> --- >>>>>> >>>>>> I need this update as VFIO on PPC64/pseries got in upstream kernel >>>>>> and this is required by VFIO-SPAPR bits in QEMU. Others may find this >>>>>> update useful too :) >>>>>> --- >>>>>> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++ >>>>>> linux-headers/asm-arm64/kvm_para.h | 1 + >>>>>> linux-headers/asm-mips/kvm.h | 81 +++++++++-------- >>>>>> linux-headers/linux/kvm.h | 3 + >>>>>> linux-headers/linux/vfio.h | 42 ++++++++- >>>>>> linux-headers/linux/virtio_config.h | 3 + >>>>>> 6 files changed, 254 insertions(+), 44 deletions(-) >>>>>> create mode 100644 linux-headers/asm-arm64/kvm.h >>>>>> create mode 100644 linux-headers/asm-arm64/kvm_para.h >>>>> >>>>> I think this should go in via the KVM tree, not trivial. >>>> >>>> I do not mind, it just went through the trivial tree last time, that's it. >>> >>> This shouldn't be routed through trivial in general as things broke too >>> often in this area. >> >> Sorry for my ignorance, but this is The Kernel, it is already there, broken >> or not, even if it is broken, qemu cannot stay isolated, no? >> This is a mechanical change, no more. > > It's a matter of keeping things bisectable. If we can detect a > breakage, we can first work around it, and then apply the header update. > And if we don't detect it, maintainers usually send pull requests when > they have time to work on breakage caused by their patches. I can see the discussion but I do not see if anyone is going to pull this through any tree. Please, somebody, pull. Thanks. -- Alexey -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
