* Re: [PATCH 0/7] Hyper-V Synthetic interrupt controller
From: Paolo Bonzini @ 2015-11-02 11:55 UTC (permalink / raw)
To: Andrey Smetanin, qemu-devel
Cc: kvm, Gleb Natapov, virtualization, Roman Kagan, Denis V. Lunev,
Vitaly Kuznetsov
In-Reply-To: <1445853060-24201-1-git-send-email-asmetanin@virtuozzo.com>
On 26/10/2015 10:50, Andrey Smetanin wrote:
> Hyper-V SynIC (synthetic interrupt controller) device
> implementation.
>
> The implementation contains:
> * msr's support
> * irq routing setup
> * irq injection
> * irq ack callback registration
> * event/message pages changes tracking at Hyper-V exit
> * Hyper-V test device to test SynIC by kvm-unit-tests
>
> Andrey Smetanin (7):
> standard-headers/x86: add Hyper-V SynIC constants
> target-i386/kvm: Hyper-V SynIC MSR's support
> linux-headers/kvm: add Hyper-V SynIC irq routing type and struct
> kvm: Hyper-V SynIC irq routing support
> linux-headers/kvm: KVM_EXIT_HYPERV type and struct
> target-i386/hyperv: Hyper-V SynIC SINT routing and vCPU exit
> hw/misc: Hyper-V test device 'hyperv-testdev'
>
> default-configs/i386-softmmu.mak | 1 +
> default-configs/x86_64-softmmu.mak | 1 +
> hw/misc/Makefile.objs | 1 +
> hw/misc/hyperv_testdev.c | 164 ++++++++++++++++++++++++++++++
> include/standard-headers/asm-x86/hyperv.h | 12 +++
> include/sysemu/kvm.h | 1 +
> kvm-all.c | 33 ++++++
> linux-headers/linux/kvm.h | 25 +++++
> target-i386/Makefile.objs | 2 +-
> target-i386/cpu-qom.h | 1 +
> target-i386/cpu.c | 1 +
> target-i386/cpu.h | 5 +
> target-i386/hyperv.c | 127 +++++++++++++++++++++++
> target-i386/hyperv.h | 42 ++++++++
> target-i386/kvm.c | 66 +++++++++++-
> target-i386/machine.c | 39 +++++++
> 16 files changed, 519 insertions(+), 2 deletions(-)
> create mode 100644 hw/misc/hyperv_testdev.c
> create mode 100644 target-i386/hyperv.c
> create mode 100644 target-i386/hyperv.h
>
> Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
> CC: "K. Y. Srinivasan" <kys@microsoft.com>
> CC: Gleb Natapov <gleb@kernel.org>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Roman Kagan <rkagan@virtuozzo.com>
> CC: Denis V. Lunev <den@openvz.org>
> CC: kvm@vger.kernel.org
> CC: virtualization@lists.linux-foundation.org
>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
^ permalink raw reply
* Re: [kvm-unit-tests PATCH] x86: hyperv_synic: Hyper-V SynIC test
From: Paolo Bonzini @ 2015-11-02 12:16 UTC (permalink / raw)
To: Andrey Smetanin, kvm
Cc: Gleb Natapov, qemu-devel, virtualization, Roman Kagan,
Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <1445853369-24435-1-git-send-email-asmetanin@virtuozzo.com>
On 26/10/2015 10:56, Andrey Smetanin wrote:
> Hyper-V SynIC is a Hyper-V synthetic interrupt controller.
>
> The test runs on every vCPU and performs the following steps:
> * read from all Hyper-V SynIC MSR's
> * setup Hyper-V SynIC evt/msg pages
> * setup SINT's routing
> * inject SINT's into destination vCPU by 'hyperv-synic-test-device'
> * wait for SINT's isr's completion
> * clear Hyper-V SynIC evt/msg pages and destroy SINT's routing
>
> Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
> CC: "K. Y. Srinivasan" <kys@microsoft.com>
> CC: Gleb Natapov <gleb@kernel.org>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Roman Kagan <rkagan@virtuozzo.com>
> CC: Denis V. Lunev <den@openvz.org>
> CC: qemu-devel@nongnu.org
> CC: virtualization@lists.linux-foundation.org
Bad news.
The test breaks with APICv, because of the following sequence of events:
1) non-auto-EOI interrupt 176 is injected into IRR and ISR
2) The PPR register is now 176
3) auto-EOI interrupt 179 is injected into IRR only, because (179 &
0xf0) <= (PPR & 0xf0)
4) interrupt 176 ISR performs an EOI
5) at this point, because virtual interrupt delivery is enabled, the
processor does not perform TPR virtualization (SDM 29.1.2).
In addition (and even worse) because virtual interrupt delivery is
enabled, an auto-EOI interrupt that was stashed in IRR can be injected
by the processor, and the auto-EOI behavior will be skipped.
The solution is to have userspace enable KVM_CAP_HYPERV_SYNIC through
KVM_ENABLE_CAP, and modify vmx.c to not use apicv on VMs that have it
enabled. This requires some changes to the callbacks that only work if
enable_apicv or !enable_apicv:
if (enable_apicv)
kvm_x86_ops->update_cr8_intercept = NULL;
else {
kvm_x86_ops->hwapic_irr_update = NULL;
kvm_x86_ops->hwapic_isr_update = NULL;
kvm_x86_ops->deliver_posted_interrupt = NULL;
kvm_x86_ops->sync_pir_to_irr = vmx_sync_pir_to_irr_dummy;
}
The question then is... does Hyper-V actually use auto-EOI interrupts?
If it doesn't, we might as well not implement them... :/
I'm keeping the kernel patches queued for my own testing, but this of
course has to be fixed before including them---which will delay this
feature to 4.5, unfortunately.
Paolo
> ---
> config/config-x86-common.mak | 5 +-
> lib/x86/msr.h | 23 +++++
> x86/hyperv_synic.c | 229 +++++++++++++++++++++++++++++++++++++++++++
> x86/run | 10 +-
> x86/unittests.cfg | 5 +
> 5 files changed, 270 insertions(+), 2 deletions(-)
> create mode 100644 x86/hyperv_synic.c
>
> diff --git a/config/config-x86-common.mak b/config/config-x86-common.mak
> index c2f9908..dc80eaa 100644
> --- a/config/config-x86-common.mak
> +++ b/config/config-x86-common.mak
> @@ -36,7 +36,8 @@ tests-common = $(TEST_DIR)/vmexit.flat $(TEST_DIR)/tsc.flat \
> $(TEST_DIR)/kvmclock_test.flat $(TEST_DIR)/eventinj.flat \
> $(TEST_DIR)/s3.flat $(TEST_DIR)/pmu.flat \
> $(TEST_DIR)/tsc_adjust.flat $(TEST_DIR)/asyncpf.flat \
> - $(TEST_DIR)/init.flat $(TEST_DIR)/smap.flat
> + $(TEST_DIR)/init.flat $(TEST_DIR)/smap.flat \
> + $(TEST_DIR)/hyperv_synic.flat
>
> ifdef API
> tests-common += api/api-sample
> @@ -108,6 +109,8 @@ $(TEST_DIR)/vmx.elf: $(cstart.o) $(TEST_DIR)/vmx.o $(TEST_DIR)/vmx_tests.o
>
> $(TEST_DIR)/debug.elf: $(cstart.o) $(TEST_DIR)/debug.o
>
> +$(TEST_DIR)/hyperv_synic.elf: $(cstart.o) $(TEST_DIR)/hyperv_synic.o
> +
> arch_clean:
> $(RM) $(TEST_DIR)/*.o $(TEST_DIR)/*.flat $(TEST_DIR)/*.elf \
> $(TEST_DIR)/.*.d lib/x86/.*.d
> diff --git a/lib/x86/msr.h b/lib/x86/msr.h
> index 281255a..54da420 100644
> --- a/lib/x86/msr.h
> +++ b/lib/x86/msr.h
> @@ -408,4 +408,27 @@
> #define MSR_VM_IGNNE 0xc0010115
> #define MSR_VM_HSAVE_PA 0xc0010117
>
> +/* Define synthetic interrupt controller model specific registers. */
> +#define HV_X64_MSR_SCONTROL 0x40000080
> +#define HV_X64_MSR_SVERSION 0x40000081
> +#define HV_X64_MSR_SIEFP 0x40000082
> +#define HV_X64_MSR_SIMP 0x40000083
> +#define HV_X64_MSR_EOM 0x40000084
> +#define HV_X64_MSR_SINT0 0x40000090
> +#define HV_X64_MSR_SINT1 0x40000091
> +#define HV_X64_MSR_SINT2 0x40000092
> +#define HV_X64_MSR_SINT3 0x40000093
> +#define HV_X64_MSR_SINT4 0x40000094
> +#define HV_X64_MSR_SINT5 0x40000095
> +#define HV_X64_MSR_SINT6 0x40000096
> +#define HV_X64_MSR_SINT7 0x40000097
> +#define HV_X64_MSR_SINT8 0x40000098
> +#define HV_X64_MSR_SINT9 0x40000099
> +#define HV_X64_MSR_SINT10 0x4000009A
> +#define HV_X64_MSR_SINT11 0x4000009B
> +#define HV_X64_MSR_SINT12 0x4000009C
> +#define HV_X64_MSR_SINT13 0x4000009D
> +#define HV_X64_MSR_SINT14 0x4000009E
> +#define HV_X64_MSR_SINT15 0x4000009F
> +
> #endif /* _ASM_X86_MSR_INDEX_H */
> diff --git a/x86/hyperv_synic.c b/x86/hyperv_synic.c
> new file mode 100644
> index 0000000..5c5a43a
> --- /dev/null
> +++ b/x86/hyperv_synic.c
> @@ -0,0 +1,229 @@
> +#include "libcflat.h"
> +#include "processor.h"
> +#include "msr.h"
> +#include "isr.h"
> +#include "vm.h"
> +#include "apic.h"
> +#include "desc.h"
> +#include "io.h"
> +#include "smp.h"
> +#include "atomic.h"
> +
> +#define MAX_CPUS 4
> +#define HYPERV_CPUID_FEATURES 0x40000003
> +#define HV_X64_MSR_SYNIC_AVAILABLE (1 << 2)
> +#define HV_SYNIC_CONTROL_ENABLE (1ULL << 0)
> +#define HV_SYNIC_SIMP_ENABLE (1ULL << 0)
> +#define HV_SYNIC_SIEFP_ENABLE (1ULL << 0)
> +#define HV_SYNIC_SINT_MASKED (1ULL << 16)
> +#define HV_SYNIC_SINT_AUTO_EOI (1ULL << 17)
> +#define HV_SYNIC_SINT_VECTOR_MASK (0xFF)
> +#define HV_SYNIC_SINT_COUNT 16
> +
> +enum {
> + HV_TEST_DEV_SINT_ROUTE_CREATE = 1,
> + HV_TEST_DEV_SINT_ROUTE_DESTROY,
> + HV_TEST_DEV_SINT_ROUTE_SET_SINT
> +};
> +
> +static atomic_t isr_enter_count[MAX_CPUS];
> +static atomic_t cpus_comp_count;
> +
> +static bool synic_supported(void)
> +{
> + return cpuid(HYPERV_CPUID_FEATURES).a & HV_X64_MSR_SYNIC_AVAILABLE;
> +}
> +
> +static void synic_sint_auto_eoi_isr(isr_regs_t *regs)
> +{
> + atomic_inc(&isr_enter_count[smp_id()]);
> +}
> +
> +static void synic_sint_isr(isr_regs_t *regs)
> +{
> + atomic_inc(&isr_enter_count[smp_id()]);
> + eoi();
> +}
> +
> +static void synic_ctl(u8 ctl, u8 vcpu_id, u8 sint)
> +{
> + outl((ctl << 16)|((vcpu_id) << 8)|sint, 0x3000);
> +}
> +
> +struct sint_vec_entry {
> + int vec;
> + bool auto_eoi;
> +};
> +
> +struct sint_vec_entry sint_vecs[HV_SYNIC_SINT_COUNT] = {
> + {0xB0, false},
> + {0xB1, false},
> + {0xB2, false},
> + {0xB3, true},
> + {0xB4, false},
> + {0xB5, false},
> + {0xB6, false},
> + {0xB7, false},
> + {0xB8, true},
> + {0xB9, false},
> + {0xBA, true},
> + {0xBB, false},
> + {0xBC, false},
> + {0xBD, false},
> + {0xBE, true},
> + {0xBF, false},
> +};
> +
> +static void synic_prepare_sint_vecs(void)
> +{
> + bool auto_eoi;
> + int i, vec;
> +
> + for (i = 0; i < HV_SYNIC_SINT_COUNT; i++) {
> + vec = sint_vecs[i].vec;
> + auto_eoi = sint_vecs[i].auto_eoi;
> + handle_irq(vec, (auto_eoi) ? synic_sint_auto_eoi_isr : synic_sint_isr);
> + }
> +}
> +
> +static void synic_sints_prepare(u8 vcpu)
> +{
> + bool auto_eoi;
> + int i, vec;
> +
> + for (i = 0; i < HV_SYNIC_SINT_COUNT; i++) {
> + vec = sint_vecs[i].vec;
> + auto_eoi = sint_vecs[i].auto_eoi;
> + wrmsr(HV_X64_MSR_SINT0 + i,
> + (u64)vec | ((auto_eoi) ? HV_SYNIC_SINT_AUTO_EOI : 0));
> + synic_ctl(HV_TEST_DEV_SINT_ROUTE_CREATE, vcpu, i);
> + }
> +}
> +
> +static void synic_test_prepare(void *ctx)
> +{
> + u64 r;
> + int i = 0;
> +
> + write_cr3((ulong)ctx);
> + irq_enable();
> +
> + rdmsr(HV_X64_MSR_SVERSION);
> + rdmsr(HV_X64_MSR_SIMP);
> + rdmsr(HV_X64_MSR_SIEFP);
> + rdmsr(HV_X64_MSR_SCONTROL);
> + for (i = 0; i < HV_SYNIC_SINT_COUNT; i++) {
> + rdmsr(HV_X64_MSR_SINT0 + i);
> + }
> + r = rdmsr(HV_X64_MSR_EOM);
> + if (r != 0) {
> + report("Hyper-V SynIC test, EOM read 0x%llx", false, r);
> + goto ret;
> + }
> +
> + wrmsr(HV_X64_MSR_SIMP, (u64)virt_to_phys(alloc_page()) |
> + HV_SYNIC_SIMP_ENABLE);
> + wrmsr(HV_X64_MSR_SIEFP, (u64)virt_to_phys(alloc_page())|
> + HV_SYNIC_SIEFP_ENABLE);
> + wrmsr(HV_X64_MSR_SCONTROL, HV_SYNIC_CONTROL_ENABLE);
> +
> + synic_sints_prepare(smp_id());
> +ret:
> + atomic_inc(&cpus_comp_count);
> +}
> +
> +static void synic_sints_test(u8 dst_vcpu)
> +{
> + int i;
> +
> + atomic_set(&isr_enter_count[dst_vcpu], 0);
> + for (i = 0; i < HV_SYNIC_SINT_COUNT; i++) {
> + synic_ctl(HV_TEST_DEV_SINT_ROUTE_SET_SINT, dst_vcpu, i);
> + }
> +
> + while (atomic_read(&isr_enter_count[dst_vcpu]) != HV_SYNIC_SINT_COUNT) {
> + pause();
> + }
> +}
> +
> +static void synic_test(void *ctx)
> +{
> + u8 dst_vcpu = (ulong)ctx;
> +
> + irq_enable();
> + synic_sints_test(dst_vcpu);
> + atomic_inc(&cpus_comp_count);
> +}
> +
> +static void synic_test_cleanup(void *ctx)
> +{
> + u8 vcpu = smp_id();
> + int i;
> +
> + irq_enable();
> + for (i = 0; i < HV_SYNIC_SINT_COUNT; i++) {
> + synic_ctl(HV_TEST_DEV_SINT_ROUTE_DESTROY, vcpu, i);
> + wrmsr(HV_X64_MSR_SINT0 + i, 0xFF|HV_SYNIC_SINT_MASKED);
> + }
> +
> + wrmsr(HV_X64_MSR_SCONTROL, 0);
> + wrmsr(HV_X64_MSR_SIMP, 0);
> + wrmsr(HV_X64_MSR_SIEFP, 0);
> + atomic_inc(&cpus_comp_count);
> +}
> +
> +int main(int ac, char **av)
> +{
> +
> + if (synic_supported()) {
> + int ncpus, i;
> +
> + setup_vm();
> + smp_init();
> + setup_idt();
> + enable_apic();
> +
> + synic_prepare_sint_vecs();
> +
> + ncpus = cpu_count();
> + if (ncpus > MAX_CPUS) {
> + ncpus = MAX_CPUS;
> + }
> + printf("ncpus = %d\n", ncpus);
> +
> + atomic_set(&cpus_comp_count, 0);
> + for (i = 0; i < ncpus; i++) {
> + on_cpu_async(i, synic_test_prepare, (void *)read_cr3());
> + }
> + while (atomic_read(&cpus_comp_count) != ncpus) {
> + pause();
> + }
> +
> + atomic_set(&cpus_comp_count, 0);
> + for (i = 0; i < ncpus; i++) {
> + on_cpu_async(i, synic_test, (void *)(ulong)(ncpus - 1 - i));
> + }
> + while (atomic_read(&cpus_comp_count) != ncpus) {
> + pause();
> + }
> +
> + atomic_set(&cpus_comp_count, 0);
> + for (i = 0; i < ncpus; i++) {
> + on_cpu_async(i, synic_test_cleanup, NULL);
> + }
> + while (atomic_read(&cpus_comp_count) != ncpus) {
> + pause();
> + }
> +
> + for (i = 0; i < ncpus; ++i) {
> + printf("isr_enter_count[%d] = %d\n",
> + i, atomic_read(&isr_enter_count[i]));
> + }
> +
> + report("Hyper-V SynIC test", true);
> + } else {
> + report("Hyper-V SynIC is not supported", true);
> + }
> +
> + return report_summary();
> +}
> diff --git a/x86/run b/x86/run
> index b4a35b2..e50ce5f 100755
> --- a/x86/run
> +++ b/x86/run
> @@ -42,7 +42,15 @@ else
> pc_testdev="-device testdev,chardev=testlog -chardev file,id=testlog,path=msr.out"
> fi
>
> -command="${qemu} -enable-kvm $pc_testdev -vnc none -serial stdio $pci_testdev -kernel"
> +if
> + ${qemu} -device '?' 2>&1 | grep -F "hyperv-testdev" > /dev/null;
> +then
> + hyperv_testdev="-device hyperv-testdev"
> +else
> + hyperv_testdev=""
> +fi
> +
> +command="${qemu} -enable-kvm $pc_testdev -vnc none -serial stdio $pci_testdev $hyperv_testdev -kernel"
> echo ${command} "$@"
>
> if [ "$DRYRUN" != "yes" ]; then
> diff --git a/x86/unittests.cfg b/x86/unittests.cfg
> index a38544f..6b19f42 100644
> --- a/x86/unittests.cfg
> +++ b/x86/unittests.cfg
> @@ -166,3 +166,8 @@ arch = x86_64
> [debug]
> file = debug.flat
> arch = x86_64
> +
> +[hyperv_synic]
> +file = hyperv_synic.flat
> +smp = 2
> +extra_params = -cpu host,hv_synic
>
^ permalink raw reply
* Re: [kvm-unit-tests PATCH] x86: hyperv_synic: Hyper-V SynIC test
From: Denis V. Lunev @ 2015-11-02 12:18 UTC (permalink / raw)
To: Paolo Bonzini, Andrey Smetanin, kvm
Cc: Gleb Natapov, qemu-devel, virtualization, Roman Kagan,
Vitaly Kuznetsov
In-Reply-To: <56375402.7060406@redhat.com>
On 11/02/2015 03:16 PM, Paolo Bonzini wrote:
> On 26/10/2015 10:56, Andrey Smetanin wrote:
>> Hyper-V SynIC is a Hyper-V synthetic interrupt controller.
>>
>> The test runs on every vCPU and performs the following steps:
>> * read from all Hyper-V SynIC MSR's
>> * setup Hyper-V SynIC evt/msg pages
>> * setup SINT's routing
>> * inject SINT's into destination vCPU by 'hyperv-synic-test-device'
>> * wait for SINT's isr's completion
>> * clear Hyper-V SynIC evt/msg pages and destroy SINT's routing
>>
>> Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
>> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
>> CC: "K. Y. Srinivasan" <kys@microsoft.com>
>> CC: Gleb Natapov <gleb@kernel.org>
>> CC: Paolo Bonzini <pbonzini@redhat.com>
>> CC: Roman Kagan <rkagan@virtuozzo.com>
>> CC: Denis V. Lunev <den@openvz.org>
>> CC: qemu-devel@nongnu.org
>> CC: virtualization@lists.linux-foundation.org
> Bad news.
>
> The test breaks with APICv, because of the following sequence of events:
>
> 1) non-auto-EOI interrupt 176 is injected into IRR and ISR
>
> 2) The PPR register is now 176
>
> 3) auto-EOI interrupt 179 is injected into IRR only, because (179 &
> 0xf0) <= (PPR & 0xf0)
>
> 4) interrupt 176 ISR performs an EOI
>
> 5) at this point, because virtual interrupt delivery is enabled, the
> processor does not perform TPR virtualization (SDM 29.1.2).
>
> In addition (and even worse) because virtual interrupt delivery is
> enabled, an auto-EOI interrupt that was stashed in IRR can be injected
> by the processor, and the auto-EOI behavior will be skipped.
>
> The solution is to have userspace enable KVM_CAP_HYPERV_SYNIC through
> KVM_ENABLE_CAP, and modify vmx.c to not use apicv on VMs that have it
> enabled. This requires some changes to the callbacks that only work if
> enable_apicv or !enable_apicv:
>
> if (enable_apicv)
> kvm_x86_ops->update_cr8_intercept = NULL;
> else {
> kvm_x86_ops->hwapic_irr_update = NULL;
> kvm_x86_ops->hwapic_isr_update = NULL;
> kvm_x86_ops->deliver_posted_interrupt = NULL;
> kvm_x86_ops->sync_pir_to_irr = vmx_sync_pir_to_irr_dummy;
> }
>
> The question then is... does Hyper-V actually use auto-EOI interrupts?
> If it doesn't, we might as well not implement them... :/
>
> I'm keeping the kernel patches queued for my own testing, but this of
> course has to be fixed before including them---which will delay this
> feature to 4.5, unfortunately.
>
> Paolo
well, the problem is that it actually uses auto EOI....
Den
^ permalink raw reply
* Re: [kvm-unit-tests PATCH] x86: hyperv_synic: Hyper-V SynIC test
From: Paolo Bonzini @ 2015-11-02 12:22 UTC (permalink / raw)
To: Denis V. Lunev, Andrey Smetanin, kvm
Cc: Gleb Natapov, qemu-devel, virtualization, Roman Kagan,
Vitaly Kuznetsov
In-Reply-To: <56375484.1000206@openvz.org>
On 02/11/2015 13:18, Denis V. Lunev wrote:
>> I'm keeping the kernel patches queued for my own testing, but this of
>> course has to be fixed before including them---which will delay this
>> feature to 4.5, unfortunately.
>
> well, the problem is that it actually uses auto EOI....
Ok, no big deal. We can just disable APICv when SynIC is enabled.
Paolo
^ permalink raw reply
* Re: [kvm-unit-tests PATCH] x86: hyperv_synic: Hyper-V SynIC test
From: Roman Kagan @ 2015-11-02 12:48 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, Gleb Natapov, qemu-devel, virtualization, Andrey Smetanin,
Denis V. Lunev, Vitaly Kuznetsov
In-Reply-To: <56375402.7060406@redhat.com>
On Mon, Nov 02, 2015 at 01:16:02PM +0100, Paolo Bonzini wrote:
> On 26/10/2015 10:56, Andrey Smetanin wrote:
> > Hyper-V SynIC is a Hyper-V synthetic interrupt controller.
> >
> > The test runs on every vCPU and performs the following steps:
> > * read from all Hyper-V SynIC MSR's
> > * setup Hyper-V SynIC evt/msg pages
> > * setup SINT's routing
> > * inject SINT's into destination vCPU by 'hyperv-synic-test-device'
> > * wait for SINT's isr's completion
> > * clear Hyper-V SynIC evt/msg pages and destroy SINT's routing
> >
> > Signed-off-by: Andrey Smetanin <asmetanin@virtuozzo.com>
> > Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
> > Signed-off-by: Denis V. Lunev <den@openvz.org>
> > CC: Vitaly Kuznetsov <vkuznets@redhat.com>
> > CC: "K. Y. Srinivasan" <kys@microsoft.com>
> > CC: Gleb Natapov <gleb@kernel.org>
> > CC: Paolo Bonzini <pbonzini@redhat.com>
> > CC: Roman Kagan <rkagan@virtuozzo.com>
> > CC: Denis V. Lunev <den@openvz.org>
> > CC: qemu-devel@nongnu.org
> > CC: virtualization@lists.linux-foundation.org
>
> Bad news.
>
> The test breaks with APICv, because of the following sequence of events:
Thanks for testing and analyzing this!
(... running around looking for an APICv-capable machine to be able to
catch this ourselves before we resubmit ...)
> The question then is... does Hyper-V actually use auto-EOI interrupts?
> If it doesn't, we might as well not implement them... :/
As Den wrote, we've yet to see a hyperv device which doesn't :(
Roman.
^ permalink raw reply
* Re: [PATCH 1/3] Provide simple noop dma ops
From: Joerg Roedel @ 2015-11-02 15:16 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, KVM, Michael Tsirkin, benh, Sebastian Ott,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446211237-111298-2-git-send-email-borntraeger@de.ibm.com>
On Fri, Oct 30, 2015 at 02:20:35PM +0100, Christian Borntraeger wrote:
> +static void *dma_noop_alloc(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t gfp,
> + struct dma_attrs *attrs)
> +{
> + void *ret;
> +
> + ret = (void *)__get_free_pages(gfp, get_order(size));
> + if (ret) {
> + memset(ret, 0, size);
There is no need to zero out the memory here. If the user wants
initialized memory it can call dma_zalloc_coherent. Having the memset
here means to clear the memory twice in the dma_zalloc_coherent path.
Otherwise it looks good.
Joerg
^ permalink raw reply
* Re: [PATCH 2/3] alpha: use common noop dma ops
From: Joerg Roedel @ 2015-11-02 15:18 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, KVM, Michael Tsirkin, benh, Sebastian Ott,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446211237-111298-3-git-send-email-borntraeger@de.ibm.com>
On Fri, Oct 30, 2015 at 02:20:36PM +0100, Christian Borntraeger wrote:
> Some of the alpha pci noop dma ops are identical to the common ones.
> Use them.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> arch/alpha/kernel/pci-noop.c | 46 ++++----------------------------------------
> 1 file changed, 4 insertions(+), 42 deletions(-)
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCH 3/3] s390/dma: Allow per device dma ops
From: Joerg Roedel @ 2015-11-02 15:21 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, KVM, Michael Tsirkin, benh, Sebastian Ott,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446211237-111298-4-git-send-email-borntraeger@de.ibm.com>
On Fri, Oct 30, 2015 at 02:20:37PM +0100, Christian Borntraeger wrote:
> As virtio-ccw now has dma ops, we can no longer default to the PCI ones.
> Make use of dev_archdata to keep the dma_ops per device. The pci devices
> now use that to override the default, and the default is changed to use
> the noop ops for everything that is not PCI. To compile without PCI
> support we also have to enable the DMA api with virtio.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> arch/s390/Kconfig | 3 ++-
> arch/s390/include/asm/device.h | 6 +++++-
> arch/s390/include/asm/dma-mapping.h | 6 ++++--
> arch/s390/pci/pci.c | 1 +
> arch/s390/pci/pci_dma.c | 4 ++--
> 5 files changed, 14 insertions(+), 6 deletions(-)
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCHv2 0/3] dma ops and virtio
From: Sebastian Ott @ 2015-11-02 15:27 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446211237-111298-1-git-send-email-borntraeger@de.ibm.com>
Hi,
On Fri, 30 Oct 2015, Christian Borntraeger wrote:
> here is the 2nd version of providing an DMA API for s390.
>
> There are some attempts to unify the dma ops (Christoph) as well
> as some attempts to make virtio use the dma API (Andy).
>
> At kernel summit we concluded that we want to use the same code on all
> platforms, whereever possible, so having a dummy dma_op might be the
> easiest solution to keep virtio-ccw as similar as possible to
> virtio-pci.Together with a fixed up patch set from Andy Lutomirski
> this seems to work.
>
> We will also need a fixup for powerc and QEMU changes to make virtio
> work with iommu on power and x86.
>
> TODO:
> - future add-on patches to also fold in x86 no iommu
> - dma_mask
> - checking?
> - make compilation of dma-noop dependent on something
>
> v1->v2:
> - initial testing
> - always use dma_noop_ops if device has no private dma_ops
> - get rid of setup in virtio_ccw,kvm_virtio
> - set CONFIG_HAS_DMA(ATTRS) for virtio (fixes compile for !PCI)
> - rename s390_dma_ops to s390_pci_dma_ops
>
> Christian Borntraeger (3):
> Provide simple noop dma ops
> alpha: use common noop dma ops
> s390/dma: Allow per device dma ops
>
> arch/alpha/kernel/pci-noop.c | 46 ++--------------------
> arch/s390/Kconfig | 3 +-
> arch/s390/include/asm/device.h | 6 ++-
> arch/s390/include/asm/dma-mapping.h | 6 ++-
> arch/s390/pci/pci.c | 1 +
> arch/s390/pci/pci_dma.c | 4 +-
> include/linux/dma-mapping.h | 2 +
> lib/Makefile | 2 +-
> lib/dma-noop.c | 77 +++++++++++++++++++++++++++++++++++++
> 9 files changed, 98 insertions(+), 49 deletions(-)
> create mode 100644 lib/dma-noop.c
>
> --
I agree with these changes in principle. As long as we don't do MMIO
(writel and friends) on a dummy mapping we're fine.
Regards,
Sebastian
^ permalink raw reply
* Re: [PATCH 1/3] Provide simple noop dma ops
From: Christian Borntraeger @ 2015-11-02 16:01 UTC (permalink / raw)
To: Joerg Roedel
Cc: linux-s390, KVM, Michael Tsirkin, benh, Sebastian Ott,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <20151102151644.GC2876@suse.de>
Am 02.11.2015 um 16:16 schrieb Joerg Roedel:
> On Fri, Oct 30, 2015 at 02:20:35PM +0100, Christian Borntraeger wrote:
>> +static void *dma_noop_alloc(struct device *dev, size_t size,
>> + dma_addr_t *dma_handle, gfp_t gfp,
>> + struct dma_attrs *attrs)
>> +{
>> + void *ret;
>> +
>> + ret = (void *)__get_free_pages(gfp, get_order(size));
>> + if (ret) {
>> + memset(ret, 0, size);
>
> There is no need to zero out the memory here. If the user wants
> initialized memory it can call dma_zalloc_coherent. Having the memset
> here means to clear the memory twice in the dma_zalloc_coherent path.
>
> Otherwise it looks good.
Thanks. Will fix.
In addition I will also make the compilation of dma-noop.o dependent
on HAS_DMA.
^ permalink raw reply
* Re: [PATCH 3/3] s390/dma: Allow per device dma ops
From: Sebastian Ott @ 2015-11-02 16:38 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446211237-111298-4-git-send-email-borntraeger@de.ibm.com>
On Fri, 30 Oct 2015, Christian Borntraeger wrote:
> As virtio-ccw now has dma ops, we can no longer default to the PCI ones.
> Make use of dev_archdata to keep the dma_ops per device. The pci devices
> now use that to override the default, and the default is changed to use
> the noop ops for everything that is not PCI. To compile without PCI
> support we also have to enable the DMA api with virtio.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] vhost: move is_le setup to the backend
From: David Miller @ 2015-11-02 20:09 UTC (permalink / raw)
To: gkurz; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <20151030114235.28847.63465.stgit@bahia.huguette.org>
From: Greg Kurz <gkurz@linux.vnet.ibm.com>
Date: Fri, 30 Oct 2015 12:42:35 +0100
> The vq->is_le field is used to fix endianness when accessing the vring via
> the cpu_to_vhost16() and vhost16_to_cpu() helpers in the following cases:
>
> 1) host is big endian and device is modern virtio
>
> 2) host has cross-endian support and device is legacy virtio with a different
> endianness than the host
>
> Both cases rely on the VHOST_SET_FEATURES ioctl, but 2) also needs the
> VHOST_SET_VRING_ENDIAN ioctl to be called by userspace. Since vq->is_le
> is only needed when the backend is active, it was decided to set it at
> backend start.
>
> This is currently done in vhost_init_used()->vhost_init_is_le() but it
> obfuscates the core vhost code. This patch moves the is_le setup to a
> dedicated function that is called from the backend code.
>
> Note vhost_net is the only backend that can pass vq->private_data == NULL to
> vhost_init_used(), hence the "if (sock)" branch.
>
> No behaviour change.
>
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Michael, I'm assuming that you will be the one taking this.
^ permalink raw reply
* Re: [PATCH net-next rfc V2 0/2] basic busy polling support for vhost_net
From: Jason Wang @ 2015-11-03 7:46 UTC (permalink / raw)
To: mst, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <56335B66.9050705@redhat.com>
On 10/30/2015 07:58 PM, Jason Wang wrote:
>
> On 10/29/2015 04:45 PM, Jason Wang wrote:
>> Hi all:
>>
>> This series tries to add basic busy polling for vhost net. The idea is
>> simple: at the end of tx processing, busy polling for new tx added
>> descriptor and rx receive socket for a while. The maximum number of
>> time (in us) could be spent on busy polling was specified through
>> module parameter.
>>
>> Test were done through:
>>
>> - 50 us as busy loop timeout
>> - Netperf 2.6
>> - Two machines with back to back connected mlx4
>> - Guest with 8 vcpus and 1 queue
>>
>> Result shows very huge improvement on both tx (at most 158%) and rr
>> (at most 53%) while rx is as much as in the past. Most cases the cpu
>> utilization is also improved:
>>
> Just notice there's something wrong in the setup. So the numbers are
> incorrect here. Will re-run and post correct number here.
>
> Sorry.
Here's the updated testing result:
1) 1 vcpu 1 queue:
TCP_RR
size/session/+thu%/+normalize%
1/ 1/ 0%/ -25%
1/ 50/ +12%/ 0%
1/ 100/ +12%/ +1%
1/ 200/ +9%/ -1%
64/ 1/ +3%/ -21%
64/ 50/ +8%/ 0%
64/ 100/ +7%/ 0%
64/ 200/ +9%/ 0%
256/ 1/ +1%/ -25%
256/ 50/ +7%/ -2%
256/ 100/ +6%/ -2%
256/ 200/ +4%/ -2%
512/ 1/ +2%/ -19%
512/ 50/ +5%/ -2%
512/ 100/ +3%/ -3%
512/ 200/ +6%/ -2%
1024/ 1/ +2%/ -20%
1024/ 50/ +3%/ -3%
1024/ 100/ +5%/ -3%
1024/ 200/ +4%/ -2%
Guest RX
size/session/+thu%/+normalize%
64/ 1/ -4%/ -5%
64/ 4/ -3%/ -10%
64/ 8/ -3%/ -5%
512/ 1/ +15%/ +1%
512/ 4/ -5%/ -5%
512/ 8/ -2%/ -4%
1024/ 1/ -5%/ -16%
1024/ 4/ -2%/ -5%
1024/ 8/ -6%/ -6%
2048/ 1/ +10%/ +5%
2048/ 4/ -8%/ -4%
2048/ 8/ -1%/ -4%
4096/ 1/ -9%/ -11%
4096/ 4/ +1%/ -1%
4096/ 8/ +1%/ 0%
16384/ 1/ +20%/ +11%
16384/ 4/ 0%/ -3%
16384/ 8/ +1%/ 0%
65535/ 1/ +36%/ +13%
65535/ 4/ -10%/ -9%
65535/ 8/ -3%/ -2%
Guest TX
size/session/+thu%/+normalize%
64/ 1/ -7%/ -16%
64/ 4/ -14%/ -23%
64/ 8/ -9%/ -20%
512/ 1/ -62%/ -56%
512/ 4/ -62%/ -56%
512/ 8/ -61%/ -53%
1024/ 1/ -66%/ -61%
1024/ 4/ -77%/ -73%
1024/ 8/ -73%/ -67%
2048/ 1/ -74%/ -75%
2048/ 4/ -77%/ -74%
2048/ 8/ -72%/ -68%
4096/ 1/ -65%/ -68%
4096/ 4/ -66%/ -63%
4096/ 8/ -62%/ -57%
16384/ 1/ -25%/ -28%
16384/ 4/ -28%/ -17%
16384/ 8/ -24%/ -10%
65535/ 1/ -17%/ -14%
65535/ 4/ -22%/ -5%
65535/ 8/ -25%/ -9%
- obvious improvement on TCP_RR (at most 12%)
- improvement on guest RX
- huge decreasing on Guest TX (at most -75%), this is probably because
virtio-net driver suffers from buffer bloat by orphaning skb before
transmission. The faster vhost it is, the smaller packet it could
produced. To reduce the impact on this, turning off gso in guest can
result the following result:
size/session/+thu%/+normalize%
64/ 1/ +3%/ -11%
64/ 4/ +4%/ -10%
64/ 8/ +4%/ -10%
512/ 1/ +2%/ +5%
512/ 4/ 0%/ -1%
512/ 8/ 0%/ 0%
1024/ 1/ +11%/ 0%
1024/ 4/ 0%/ -1%
1024/ 8/ +3%/ +1%
2048/ 1/ +4%/ -1%
2048/ 4/ +8%/ +3%
2048/ 8/ 0%/ -1%
4096/ 1/ +4%/ -1%
4096/ 4/ +1%/ 0%
4096/ 8/ +2%/ 0%
16384/ 1/ +2%/ -2%
16384/ 4/ +3%/ +1%
16384/ 8/ 0%/ -1%
65535/ 1/ +9%/ +7%
65535/ 4/ 0%/ -3%
65535/ 8/ -1%/ -1%
2) 8 vcpus 1 queue:
TCP_RR
size/session/+thu%/+normalize%
1/ 1/ +5%/ -14%
1/ 50/ +2%/ +1%
1/ 100/ 0%/ -1%
1/ 200/ 0%/ 0%
64/ 1/ 0%/ -25%
64/ 50/ +5%/ +5%
64/ 100/ 0%/ 0%
64/ 200/ 0%/ -1%
256/ 1/ 0%/ -30%
256/ 50/ 0%/ 0%
256/ 100/ -2%/ -2%
256/ 200/ 0%/ 0%
512/ 1/ +1%/ -23%
512/ 50/ +1%/ +1%
512/ 100/ +1%/ 0%
512/ 200/ +1%/ +1%
1024/ 1/ +1%/ -23%
1024/ 50/ +5%/ +5%
1024/ 100/ 0%/ -1%
1024/ 200/ 0%/ 0%
Guest RX
size/session/+thu%/+normalize%
64/ 1/ +1%/ +1%
64/ 4/ -2%/ +1%
64/ 8/ +6%/ +19%
512/ 1/ +5%/ -7%
512/ 4/ -4%/ -4%
512/ 8/ 0%/ 0%
1024/ 1/ +1%/ +2%
1024/ 4/ -2%/ -2%
1024/ 8/ -1%/ +7%
2048/ 1/ +8%/ -2%
2048/ 4/ 0%/ +5%
2048/ 8/ -1%/ +13%
4096/ 1/ -1%/ +2%
4096/ 4/ 0%/ +6%
4096/ 8/ -2%/ +15%
16384/ 1/ -1%/ 0%
16384/ 4/ -2%/ -1%
16384/ 8/ -2%/ +2%
65535/ 1/ -2%/ 0%
65535/ 4/ -3%/ -3%
65535/ 8/ -2%/ +2%
Guest TX
size/session/+thu%/+normalize%
64/ 1/ +6%/ +3%
64/ 4/ +11%/ +8%
64/ 8/ 0%/ 0%
512/ 1/ +19%/ +18%
512/ 4/ -4%/ +1%
512/ 8/ -1%/ -1%
1024/ 1/ 0%/ +8%
1024/ 4/ -1%/ -1%
1024/ 8/ 0%/ +1%
2048/ 1/ +1%/ 0%
2048/ 4/ -1%/ -2%
2048/ 8/ 0%/ 0%
4096/ 1/ +12%/ +14%
4096/ 4/ 0%/ -1%
4096/ 8/ -2%/ -1%
16384/ 1/ +9%/ +6%
16384/ 4/ +3%/ -1%
16384/ 8/ +2%/ -1%
65535/ 1/ +1%/ -2%
65535/ 4/ 0%/ -4%
65535/ 8/ 0%/ -2%
- latency get improved a little bit
- small improvement on single session rx
- no other obvious changes
- this may because 8 vcpu could give enough stress on a single vhost
thread. Then the busy polling was not trigged enough (unless on light
load case e.g 1 session TCP_RR).
3) 8 vcpus 8 queues
8 vcpu 8 queue
TCP_RR
size/session/+thu%/+normalize%
1/ 1/ +6%/ -16%
1/ 50/ +14%/ +1%
1/ 100/ +17%/ +3%
1/ 200/ +16%/ +2%
64/ 1/ +2%/ -19%
64/ 50/ +10%/ 0%
64/ 100/ +17%/ +5%
64/ 200/ +15%/ +3%
256/ 1/ 0%/ -19%
256/ 50/ +5%/ -3%
256/ 100/ +4%/ -3%
256/ 200/ +2%/ -4%
512/ 1/ +4%/ -19%
512/ 50/ +7%/ -2%
512/ 100/ +4%/ -4%
512/ 200/ +3%/ -4%
1024/ 1/ +9%/ -19%
1024/ 50/ +6%/ -2%
1024/ 100/ +5%/ -3%
1024/ 200/ +5%/ -3%
Guest RX
size/session/+thu%/+normalize%
64/ 1/ +18%/ +13%
64/ 4/ 0%/ -1%
64/ 8/ -4%/ -11%
512/ 1/ +3%/ -6%
512/ 4/ +1%/ -11%
512/ 8/ -1%/ -7%
1024/ 1/ 0%/ -9%
1024/ 4/ +9%/ -16%
1024/ 8/ -1%/ -11%
2048/ 1/ 0%/ -2%
2048/ 4/ 0%/ -16%
2048/ 8/ -1%/ -2%
4096/ 1/ +3%/ 0%
4096/ 4/ -1%/ -12%
4096/ 8/ 0%/ -5%
16384/ 1/ -2%/ -6%
16384/ 4/ 0%/ -6%
16384/ 8/ 0%/ -6%
65535/ 1/ 0%/ 0%
65535/ 4/ 0%/ -9%
65535/ 8/ 0%/ +1%
Guest TX
size/session/+thu%/+normalize%
64/ 1/ +7%/ +3%
64/ 4/ +6%/ 0%
64/ 8/ +10%/ +5%
512/ 1/ 0%/ +14%
512/ 4/ +9%/ -1%
512/ 8/ +14%/ +4%
1024/ 1/ +44%/ +37%
1024/ 4/ +6%/ +2%
1024/ 8/ +19%/ +12%
2048/ 1/ -14%/ -16%
2048/ 4/ +11%/ +8%
2048/ 8/ +26%/ +28%
4096/ 1/ +21%/ +19%
4096/ 4/ +2%/ +10%
4096/ 8/ +14%/ +7%
16384/ 1/ +12%/ +4%
16384/ 4/ +7%/ +2%
16384/ 8/ +2%/ +9%
65535/ 1/ -3%/ -5%
65535/ 4/ +9%/ +5%
65535/ 8/ 0%/ -8%
- TCP_RR get obviously improved (at most 17%)
- obvious improvement on Guest TX (at most 44%)
^ permalink raw reply
* [RFC PATCH] x86/paravirt: Kill some unused patching functions
From: Borislav Petkov @ 2015-11-03 9:18 UTC (permalink / raw)
To: LKML
Cc: Juergen Gross, Jeremy Fitzhardinge, Peter Zijlstra (Intel),
virtualization, Chris Wright, Ingo Molnar, Andy Lutomirski,
H. Peter Anvin, xen-devel, Andrew Morton, Thomas Gleixner
From: Borislav Petkov <bp@suse.de>
paravirt_patch_ignore() is completely unused and paravirt_patch_nop()
doesn't do a whole lot. Remove them both.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: virtualization@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
---
arch/x86/include/asm/paravirt_types.h | 2 --
arch/x86/kernel/paravirt.c | 13 +------------
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
index 31247b5bff7c..e1f31dfc3b31 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -402,10 +402,8 @@ extern struct pv_lock_ops pv_lock_ops;
__visible extern const char start_##ops##_##name[], end_##ops##_##name[]; \
asm(NATIVE_LABEL("start_", ops, name) code NATIVE_LABEL("end_", ops, name))
-unsigned paravirt_patch_nop(void);
unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
-unsigned paravirt_patch_ignore(unsigned len);
unsigned paravirt_patch_call(void *insnbuf,
const void *target, u16 tgt_clobbers,
unsigned long addr, u16 site_clobbers,
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index c2130aef3f9d..4f32a10979db 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -74,16 +74,6 @@ void __init default_banner(void)
/* Undefined instruction for dealing with missing ops pointers. */
static const unsigned char ud2a[] = { 0x0f, 0x0b };
-unsigned paravirt_patch_nop(void)
-{
- return 0;
-}
-
-unsigned paravirt_patch_ignore(unsigned len)
-{
- return len;
-}
-
struct branch {
unsigned char opcode;
u32 delta;
@@ -152,8 +142,7 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers, void *insnbuf,
/* If there's no function, patch it with a ud2a (BUG) */
ret = paravirt_patch_insns(insnbuf, len, ud2a, ud2a+sizeof(ud2a));
else if (opfunc == _paravirt_nop)
- /* If the operation is a nop, then nop the callsite */
- ret = paravirt_patch_nop();
+ ret = 0;
/* identity functions just return their single argument */
else if (opfunc == _paravirt_ident_32)
--
2.3.5
^ permalink raw reply related
* Re: [PATCH v3 0/3] virtio DMA API core stuff
From: Paolo Bonzini @ 2015-11-03 10:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Andy Lutomirski
Cc: linux-s390, Joerg Roedel, KVM, Benjamin Herrenschmidt,
Sebastian Ott, linux-kernel@vger.kernel.org, Linux Virtualization,
Christian Borntraeger, Andy Lutomirski, David Woodhouse,
Christoph Hellwig, Martin Schwidefsky
In-Reply-To: <20151029104301-mutt-send-email-mst@redhat.com>
On 29/10/2015 10:01, Michael S. Tsirkin wrote:
> > Everyone seems to agree that x86's emulated Q35 thing
> > is just buggy right now and should be taught to use the existing ACPI
> > mechanism for enumerating passthrough devices.
>
> I'm not sure what ACPI has to do with it.
> It's about a way for guest users to specify whether
> they want to bypass an IOMMU for a given device.
It's not configured in the guest, it's configured _when starting_ the
guest (e.g. -device some-pci-device,iommu-bypass=on) and it is reflected
in the DMAR table or the device tree.
The default for virtio and VFIO is to bypass the IOMMU. Changing the
default can be supported (virtio) or not (VFIO, vhost-user). Hotplug
need to check whether the parent bridge is has the same setting that the
user desires for the new device.
> 1. virtio ignores the iommu
> 2. vhost user ignores the iommu
> 3. dataplane ignores the iommu
> 4. vhost-net ignores the iommu
> 5. VFIO ignores the iommu
>
> I think so far I only saw patches for 1 above.
1 and 3 are easy. For 2 and 5 you can simply forbid configurations with
vhost-user/VFIO behind an IOMMU. For 4 QEMU can simply not activate
vhost-net and use the userspace fallback.
However, IOMMU support in QEMU is experimental. We can do things a step
at a time.
Paolo
^ permalink raw reply
* [PATCHv3 0/3] dma ops and virtio
From: Christian Borntraeger @ 2015-11-03 11:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, Christian Borntraeger, virtualization,
Martin Schwidefsky, Paolo Bonzini, dwmw2, Christoph Hellwig
Andy,
this is the next and hopefully last version. Seems to work fine
when replacing the previous patches in your tree. I have some
reviews/acks for patch 2 and 3. patch 1 still needs one ack.
Can you replace the patches in your tree and carry them along
with your changes?
old introduction:
-----
There are some attempts to unify the dma ops (Christoph) as well
as some attempts to make virtio use the dma API (Andy).
At kernel summit we concluded that we want to use the same code on all
platforms, whereever possible, so having a dummy dma_op might be the
easiest solution to keep virtio-ccw as similar as possible to
virtio-pci.Together with a fixed up patch set from Andy Lutomirski
this seems to work.
We will also need a fixup for powerc and QEMU changes to make virtio
work with iommu on power and x86.
----
v2->v3:
- make dma-noop depend on HAS_DMA
- do not do memset on alloc
- prefix patches with *dma*
v1->v2:
- initial testing
- always use dma_noop_ops if device has no private dma_ops
- get rid of setup in virtio_ccw,kvm_virtio
- set CONFIG_HAS_DMA(ATTRS) for virtio (fixes compile for !PCI)
- rename s390_dma_ops to s390_pci_dma_ops
Christian Borntraeger (3):
dma: Provide simple noop dma ops
alpha/dma: use common noop dma ops
s390/dma: Allow per device dma ops
arch/alpha/kernel/pci-noop.c | 46 ++---------------------
arch/s390/Kconfig | 3 +-
arch/s390/include/asm/device.h | 6 ++-
arch/s390/include/asm/dma-mapping.h | 6 ++-
arch/s390/pci/pci.c | 1 +
arch/s390/pci/pci_dma.c | 4 +-
include/linux/dma-mapping.h | 2 +
lib/Makefile | 1 +
lib/dma-noop.c | 75 +++++++++++++++++++++++++++++++++++++
9 files changed, 96 insertions(+), 48 deletions(-)
create mode 100644 lib/dma-noop.c
--
2.4.3
^ permalink raw reply
* [PATCH 1/3] dma: Provide simple noop dma ops
From: Christian Borntraeger @ 2015-11-03 11:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, Christian Borntraeger, virtualization,
Martin Schwidefsky, Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446551679-33492-1-git-send-email-borntraeger@de.ibm.com>
We are going to require dma_ops for several common drivers, even for
systems that do have an identity mapping. Lets provide some minimal
no-op dma_ops that can be used for that purpose.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
include/linux/dma-mapping.h | 2 ++
lib/Makefile | 1 +
lib/dma-noop.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 78 insertions(+)
create mode 100644 lib/dma-noop.c
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index ac07ff0..7912f54 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -66,6 +66,8 @@ struct dma_map_ops {
int is_phys;
};
+extern struct dma_map_ops dma_noop_ops;
+
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
#define DMA_MASK_NONE 0x0ULL
diff --git a/lib/Makefile b/lib/Makefile
index 13a7c6a..92d6135 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -18,6 +18,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
obj-$(CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS) += usercopy.o
lib-$(CONFIG_MMU) += ioremap.o
lib-$(CONFIG_SMP) += cpumask.o
+lib-$(CONFIG_HAS_DMA) += dma-noop.o
lib-y += kobject.o klist.o
obj-y += lockref.o
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
new file mode 100644
index 0000000..7214564
--- /dev/null
+++ b/lib/dma-noop.c
@@ -0,0 +1,75 @@
+/*
+ * lib/dma-noop.c
+ *
+ * Simple DMA noop-ops that map 1:1 with memory
+ */
+#include <linux/export.h>
+#include <linux/mm.h>
+#include <linux/dma-mapping.h>
+#include <linux/scatterlist.h>
+
+static void *dma_noop_alloc(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ struct dma_attrs *attrs)
+{
+ void *ret;
+
+ ret = (void *)__get_free_pages(gfp, get_order(size));
+ if (ret)
+ *dma_handle = virt_to_phys(ret);
+ return ret;
+}
+
+static void dma_noop_free(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_addr,
+ struct dma_attrs *attrs)
+{
+ free_pages((unsigned long)cpu_addr, get_order(size));
+}
+
+static dma_addr_t dma_noop_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ return page_to_phys(page) + offset;
+}
+
+static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ for_each_sg(sgl, sg, nents, i) {
+ void *va;
+
+ BUG_ON(!sg_page(sg));
+ va = sg_virt(sg);
+ sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
+ sg_dma_len(sg) = sg->length;
+ }
+
+ return nents;
+}
+
+static int dma_noop_mapping_error(struct device *dev, dma_addr_t dma_addr)
+{
+ return 0;
+}
+
+static int dma_noop_supported(struct device *dev, u64 mask)
+{
+ return 1;
+}
+
+struct dma_map_ops dma_noop_ops = {
+ .alloc = dma_noop_alloc,
+ .free = dma_noop_free,
+ .map_page = dma_noop_map_page,
+ .map_sg = dma_noop_map_sg,
+ .mapping_error = dma_noop_mapping_error,
+ .dma_supported = dma_noop_supported,
+};
+
+EXPORT_SYMBOL(dma_noop_ops);
--
2.4.3
^ permalink raw reply related
* [PATCH 2/3] alpha/dma: use common noop dma ops
From: Christian Borntraeger @ 2015-11-03 11:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, Christian Borntraeger, virtualization,
Martin Schwidefsky, Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446551679-33492-1-git-send-email-borntraeger@de.ibm.com>
Some of the alpha pci noop dma ops are identical to the common ones.
Use them.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
---
arch/alpha/kernel/pci-noop.c | 46 ++++----------------------------------------
1 file changed, 4 insertions(+), 42 deletions(-)
diff --git a/arch/alpha/kernel/pci-noop.c b/arch/alpha/kernel/pci-noop.c
index 2b1f4a1..8e735b5e 100644
--- a/arch/alpha/kernel/pci-noop.c
+++ b/arch/alpha/kernel/pci-noop.c
@@ -123,44 +123,6 @@ static void *alpha_noop_alloc_coherent(struct device *dev, size_t size,
return ret;
}
-static void alpha_noop_free_coherent(struct device *dev, size_t size,
- void *cpu_addr, dma_addr_t dma_addr,
- struct dma_attrs *attrs)
-{
- free_pages((unsigned long)cpu_addr, get_order(size));
-}
-
-static dma_addr_t alpha_noop_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir,
- struct dma_attrs *attrs)
-{
- return page_to_pa(page) + offset;
-}
-
-static int alpha_noop_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
- enum dma_data_direction dir, struct dma_attrs *attrs)
-{
- int i;
- struct scatterlist *sg;
-
- for_each_sg(sgl, sg, nents, i) {
- void *va;
-
- BUG_ON(!sg_page(sg));
- va = sg_virt(sg);
- sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
- sg_dma_len(sg) = sg->length;
- }
-
- return nents;
-}
-
-static int alpha_noop_mapping_error(struct device *dev, dma_addr_t dma_addr)
-{
- return 0;
-}
-
static int alpha_noop_supported(struct device *dev, u64 mask)
{
return mask < 0x00ffffffUL ? 0 : 1;
@@ -168,10 +130,10 @@ static int alpha_noop_supported(struct device *dev, u64 mask)
struct dma_map_ops alpha_noop_ops = {
.alloc = alpha_noop_alloc_coherent,
- .free = alpha_noop_free_coherent,
- .map_page = alpha_noop_map_page,
- .map_sg = alpha_noop_map_sg,
- .mapping_error = alpha_noop_mapping_error,
+ .free = dma_noop_free_coherent,
+ .map_page = dma_noop_map_page,
+ .map_sg = dma_noop_map_sg,
+ .mapping_error = dma_noop_mapping_error,
.dma_supported = alpha_noop_supported,
};
--
2.4.3
^ permalink raw reply related
* [PATCH 3/3] s390/dma: Allow per device dma ops
From: Christian Borntraeger @ 2015-11-03 11:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, Christian Borntraeger, virtualization,
Martin Schwidefsky, Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446551679-33492-1-git-send-email-borntraeger@de.ibm.com>
As virtio-ccw now has dma ops, we can no longer default to the PCI ones.
Make use of dev_archdata to keep the dma_ops per device. The pci devices
now use that to override the default, and the default is changed to use
the noop ops for everything that is not PCI. To compile without PCI
support we also have to enable the DMA api with virtio.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
---
arch/s390/Kconfig | 3 ++-
arch/s390/include/asm/device.h | 6 +++++-
arch/s390/include/asm/dma-mapping.h | 6 ++++--
arch/s390/pci/pci.c | 1 +
arch/s390/pci/pci_dma.c | 4 ++--
5 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 1d57000..04f0e02 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -113,6 +113,7 @@ config S390
select GENERIC_FIND_FIRST_BIT
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
+ select HAS_DMA
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_EARLY_PFN_TO_NID
@@ -124,6 +125,7 @@ config S390
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
select HAVE_DEBUG_KMEMLEAK
+ select HAVE_DMA_ATTRS
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_FTRACE_MCOUNT_RECORD
@@ -580,7 +582,6 @@ config QDIO
menuconfig PCI
bool "PCI support"
- select HAVE_DMA_ATTRS
select PCI_MSI
help
Enable PCI support.
diff --git a/arch/s390/include/asm/device.h b/arch/s390/include/asm/device.h
index d8f9872..4a9f35e 100644
--- a/arch/s390/include/asm/device.h
+++ b/arch/s390/include/asm/device.h
@@ -3,5 +3,9 @@
*
* This file is released under the GPLv2
*/
-#include <asm-generic/device.h>
+struct dev_archdata {
+ struct dma_map_ops *dma_ops;
+};
+struct pdev_archdata {
+};
diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h
index b3fd54d..cb05f5c 100644
--- a/arch/s390/include/asm/dma-mapping.h
+++ b/arch/s390/include/asm/dma-mapping.h
@@ -11,11 +11,13 @@
#define DMA_ERROR_CODE (~(dma_addr_t) 0x0)
-extern struct dma_map_ops s390_dma_ops;
+extern struct dma_map_ops s390_pci_dma_ops;
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
{
- return &s390_dma_ops;
+ if (dev && dev->archdata.dma_ops)
+ return dev->archdata.dma_ops;
+ return &dma_noop_ops;
}
static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 7ef12a3..fa41605 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -649,6 +649,7 @@ int pcibios_add_device(struct pci_dev *pdev)
zdev->pdev = pdev;
pdev->dev.groups = zpci_attr_groups;
+ pdev->dev.archdata.dma_ops = &s390_pci_dma_ops;
zpci_map_resources(pdev);
for (i = 0; i < PCI_BAR_COUNT; i++) {
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 37505b8..ea39c3f 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -495,7 +495,7 @@ static int __init dma_debug_do_init(void)
}
fs_initcall(dma_debug_do_init);
-struct dma_map_ops s390_dma_ops = {
+struct dma_map_ops s390_pci_dma_ops = {
.alloc = s390_dma_alloc,
.free = s390_dma_free,
.map_sg = s390_dma_map_sg,
@@ -506,7 +506,7 @@ struct dma_map_ops s390_dma_ops = {
.is_phys = 0,
/* dma_supported is unconditionally true without a callback */
};
-EXPORT_SYMBOL_GPL(s390_dma_ops);
+EXPORT_SYMBOL_GPL(s390_pci_dma_ops);
static int __init s390_iommu_setup(char *str)
{
--
2.4.3
^ permalink raw reply related
* Re: [PATCH 3/3] s390/dma: Allow per device dma ops
From: Cornelia Huck @ 2015-11-03 12:26 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, virtualization, Andy Lutomirski,
Martin Schwidefsky, Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446551679-33492-4-git-send-email-borntraeger@de.ibm.com>
On Tue, 3 Nov 2015 12:54:39 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> As virtio-ccw now has dma ops, we can no longer default to the PCI ones.
> Make use of dev_archdata to keep the dma_ops per device. The pci devices
> now use that to override the default, and the default is changed to use
> the noop ops for everything that is not PCI. To compile without PCI
> support we also have to enable the DMA api with virtio.
Not only with virtio, but generally, right?
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Reviewed-by: Joerg Roedel <jroedel@suse.de>
> Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
> ---
> arch/s390/Kconfig | 3 ++-
> arch/s390/include/asm/device.h | 6 +++++-
> arch/s390/include/asm/dma-mapping.h | 6 ++++--
> arch/s390/pci/pci.c | 1 +
> arch/s390/pci/pci_dma.c | 4 ++--
> 5 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 1d57000..04f0e02 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -113,6 +113,7 @@ config S390
> select GENERIC_FIND_FIRST_BIT
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_TIME_VSYSCALL
> + select HAS_DMA
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_EARLY_PFN_TO_NID
> @@ -124,6 +125,7 @@ config S390
> select HAVE_CMPXCHG_DOUBLE
> select HAVE_CMPXCHG_LOCAL
> select HAVE_DEBUG_KMEMLEAK
> + select HAVE_DMA_ATTRS
> select HAVE_DYNAMIC_FTRACE
> select HAVE_DYNAMIC_FTRACE_WITH_REGS
> select HAVE_FTRACE_MCOUNT_RECORD
> @@ -580,7 +582,6 @@ config QDIO
>
> menuconfig PCI
> bool "PCI support"
> - select HAVE_DMA_ATTRS
> select PCI_MSI
> help
> Enable PCI support.
Hm. Further down in this file, there's
config HAS_DMA
def_bool PCI
select HAVE_DMA_API_DEBUG
Should we maybe select HAVE_DMA_API_DEBUG above, drop the HAS_DMA
config option and rely on not defining NO_DMA instead?
Otherwise, the patch looks good to me.
^ permalink raw reply
* Last Call for Papers - WorldCIST'2016 - Deadline: November 15, 2015
From: Maria Lemos @ 2015-11-03 18:52 UTC (permalink / raw)
To: virtualization
[-- Attachment #1: Type: text/plain, Size: 7308 bytes --]
--
---- Apologize if you receive multiple copies of this email, or if its content is irrelevant for you.
------ Please forward for your contacts. Thank you so much!
----
--
---------
WorldCIST'16 - 4th World Conference on Information Systems and Technologies
Recife, PE, Brazil
22th-24th of March 2016
http://www.aisti.eu/worldcist16/
-------------------------------------------
SCOPE
The WorldCist'16 - 4th World Conference on Information Systems and Technologies ( http://www.aisti.eu/worldcist16/ ), to be held at Recife, PE, Brazil, 22 - 24 March 2016, is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.
We are pleased to invite you to submit your papers to WorldCist'16. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
THEMES
Submitted papers should be related with one or more of the main themes proposed for the Conference:
A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Health Informatics (HIS);
K) Information Technologies in Education (ITE);
L) Information Technologies in Radiocommunications (ITR).
TYPES OF SUBMISSIONS AND DECISIONS
Four types of papers can be submitted:
- Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.
- Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.
-Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.
- Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.
Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see Instructions for Authors at Springer Website or download a DOC example) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version, saved in Word or Latex format and also in PDF format. These files must be accompanied by the Consent to Publication form filled out, in a ZIP file, and uploaded at the conference management system.
All papers will be subjected to a “double-blind review” by at least two members of the Program Committee.
Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.
The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.
The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.
PUBLICATION AND INDEXING
To ensure that a full paper, short paper, poster paper or company paper is published in the Proceedings, at least one of the authors must be fully registered by the 27th of December 2015, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published in the Conference Proceedings. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration.
Full and short papers will be published in Proceedings by Springer, in a book of Advances in Intelligent Systems and Computing series. Poster and company papers will be published by AISTI.
Published full and short papers will be submitted for indexation by ISI, EI-Compendex, SCOPUS and DBLP, among others, and will be available in the SpringerLink Digital Library.
The authors of the best selected papers will be invited to extend them for publication in international journals indexed by ISI/SCI, SCOPUS and DBLP, among others, such as:
- International Journal of Neural Systems (IF: 6.507)
- Integrated Computer-Aided Engineering (IF: 4.698)
- Computers in Human Behavior (IF: 2.694)
- Journal of Medical Systems (IF: 2.213)
- International Journal of Computer-Supported Collaborative Learning (IF: 1.841)
- Journal of Intelligent & Fuzzy Systems (IF: 1.812)
- Telemedicine and e-Health (IF: 1.668)
- International Journal of Information Management (IF: 1.550)
- Engineering Computations (IF: 1.495)
- Electronic Commerce Research and Applications (IF: 1.482)
- Telematics and Informatics (IF: 1.120)
- Journal of Evaluation in Clinical Practice (IF: 1.084)
- Ethics and Information Technology (IF: 1.021)
- Int. Journal of Computers Communications & Control (IF: 0.746)
- IET Software (IF: 0.595)
- Knowledge Management Research & Practice (IF: 0.554)
- AI Communications (IF: 0.547)
- Computing and Informatics (IF: 0.504)
- Universal Access in the Information Society (IF: 0.475)
- Journal of Global Information Management (IF: 0.424)
- Journal of Internet Services and Applications (SJR: 0.88)
- Journal of Hospitality and Tourism Technology (SJR: 0.41)
- VINE - The Journal of Information and Knowledge Management Systems (SJR: 0.24)
- International Journal of Online Engineering (SJR: 0.21)
- Int. Journal of Emerging Technologies in Learning (SJR: 0.12)
- Computer Methods in Biomechanics and Biomedical Engineering: Imaging & Visualization
IMPORTANT DATES
Paper Submission: November 15, 2015
Notification of Acceptance: December 13, 2015
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: December 27, 2015.
Camera-ready Submission: December 31, 2015
-
WorldCIST'16
http://www.aisti.eu/worldcist16/
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 3/3] s390/dma: Allow per device dma ops
From: Christian Borntraeger @ 2015-11-05 9:33 UTC (permalink / raw)
To: Cornelia Huck
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, virtualization, Andy Lutomirski,
Martin Schwidefsky, Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <20151103132615.53002e05.cornelia.huck@de.ibm.com>
Am 03.11.2015 um 13:26 schrieb Cornelia Huck:
> On Tue, 3 Nov 2015 12:54:39 +0100
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
>> As virtio-ccw now has dma ops, we can no longer default to the PCI ones.
>> Make use of dev_archdata to keep the dma_ops per device. The pci devices
>> now use that to override the default, and the default is changed to use
>> the noop ops for everything that is not PCI. To compile without PCI
>> support we also have to enable the DMA api with virtio.
>
> Not only with virtio, but generally, right?
Yes, will update the patch description.
>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> Reviewed-by: Joerg Roedel <jroedel@suse.de>
>> Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
>> ---
>> arch/s390/Kconfig | 3 ++-
>> arch/s390/include/asm/device.h | 6 +++++-
>> arch/s390/include/asm/dma-mapping.h | 6 ++++--
>> arch/s390/pci/pci.c | 1 +
>> arch/s390/pci/pci_dma.c | 4 ++--
>> 5 files changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>> index 1d57000..04f0e02 100644
>> --- a/arch/s390/Kconfig
>> +++ b/arch/s390/Kconfig
>> @@ -113,6 +113,7 @@ config S390
>> select GENERIC_FIND_FIRST_BIT
>> select GENERIC_SMP_IDLE_THREAD
>> select GENERIC_TIME_VSYSCALL
>> + select HAS_DMA
>> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
>> select HAVE_ARCH_AUDITSYSCALL
>> select HAVE_ARCH_EARLY_PFN_TO_NID
>> @@ -124,6 +125,7 @@ config S390
>> select HAVE_CMPXCHG_DOUBLE
>> select HAVE_CMPXCHG_LOCAL
>> select HAVE_DEBUG_KMEMLEAK
>> + select HAVE_DMA_ATTRS
>> select HAVE_DYNAMIC_FTRACE
>> select HAVE_DYNAMIC_FTRACE_WITH_REGS
>> select HAVE_FTRACE_MCOUNT_RECORD
>> @@ -580,7 +582,6 @@ config QDIO
>>
>> menuconfig PCI
>> bool "PCI support"
>> - select HAVE_DMA_ATTRS
>> select PCI_MSI
>> help
>> Enable PCI support.
>
> Hm. Further down in this file, there's
>
> config HAS_DMA
> def_bool PCI
> select HAVE_DMA_API_DEBUG
>
> Should we maybe select HAVE_DMA_API_DEBUG above, drop the HAS_DMA
> config option and rely on not defining NO_DMA instead?
Hmm, yes. That would simplify things a lot. Right now we include
lib/Kconfig (which defines HAS_DMA) and define it ourselfes in
arch/s390/Kconfig. WHoever comes first wins. Adding a select statement
would make this even more complicated.
Andy, I will simply send you a respin of this patch.
^ permalink raw reply
* Re: [RFC PATCH] x86/paravirt: Kill some unused patching functions
From: Juergen Gross @ 2015-11-05 11:15 UTC (permalink / raw)
To: Borislav Petkov, LKML
Cc: Jeremy Fitzhardinge, Peter Zijlstra (Intel), virtualization,
Chris Wright, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
xen-devel, Andrew Morton, Thomas Gleixner
In-Reply-To: <1446542329-32037-1-git-send-email-bp@alien8.de>
On 11/03/2015 10:18 AM, Borislav Petkov wrote:
> From: Borislav Petkov <bp@suse.de>
>
> paravirt_patch_ignore() is completely unused and paravirt_patch_nop()
> doesn't do a whole lot. Remove them both.
>
> Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Chris Wright <chrisw@sous-sol.org>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: virtualization@lists.linux-foundation.org
> Cc: xen-devel@lists.xenproject.org
> ---
> arch/x86/include/asm/paravirt_types.h | 2 --
> arch/x86/kernel/paravirt.c | 13 +------------
> 2 files changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h
> index 31247b5bff7c..e1f31dfc3b31 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -402,10 +402,8 @@ extern struct pv_lock_ops pv_lock_ops;
> __visible extern const char start_##ops##_##name[], end_##ops##_##name[]; \
> asm(NATIVE_LABEL("start_", ops, name) code NATIVE_LABEL("end_", ops, name))
>
> -unsigned paravirt_patch_nop(void);
> unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
> unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
> -unsigned paravirt_patch_ignore(unsigned len);
> unsigned paravirt_patch_call(void *insnbuf,
> const void *target, u16 tgt_clobbers,
> unsigned long addr, u16 site_clobbers,
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index c2130aef3f9d..4f32a10979db 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -74,16 +74,6 @@ void __init default_banner(void)
> /* Undefined instruction for dealing with missing ops pointers. */
> static const unsigned char ud2a[] = { 0x0f, 0x0b };
>
> -unsigned paravirt_patch_nop(void)
> -{
> - return 0;
> -}
> -
> -unsigned paravirt_patch_ignore(unsigned len)
> -{
> - return len;
> -}
> -
> struct branch {
> unsigned char opcode;
> u32 delta;
> @@ -152,8 +142,7 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers, void *insnbuf,
> /* If there's no function, patch it with a ud2a (BUG) */
> ret = paravirt_patch_insns(insnbuf, len, ud2a, ud2a+sizeof(ud2a));
> else if (opfunc == _paravirt_nop)
> - /* If the operation is a nop, then nop the callsite */
> - ret = paravirt_patch_nop();
> + ret = 0;
>
> /* identity functions just return their single argument */
> else if (opfunc == _paravirt_ident_32)
>
^ permalink raw reply
* Re: [PATCH 1/3] dma: Provide simple noop dma ops
From: Joerg Roedel @ 2015-11-05 13:31 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linux-s390, KVM, Michael Tsirkin, benh, Sebastian Ott,
virtualization, Martin Schwidefsky, Andy Lutomirski,
Paolo Bonzini, dwmw2, Christoph Hellwig
In-Reply-To: <1446551679-33492-2-git-send-email-borntraeger@de.ibm.com>
On Tue, Nov 03, 2015 at 12:54:37PM +0100, Christian Borntraeger wrote:
> We are going to require dma_ops for several common drivers, even for
> systems that do have an identity mapping. Lets provide some minimal
> no-op dma_ops that can be used for that purpose.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> include/linux/dma-mapping.h | 2 ++
> lib/Makefile | 1 +
> lib/dma-noop.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 78 insertions(+)
> create mode 100644 lib/dma-noop.c
Reviewed-by: Joerg Roedel <jroedel@suse.de>
^ permalink raw reply
* Re: [PATCH 3/3] s390/dma: Allow per device dma ops
From: Andy Lutomirski @ 2015-11-05 19:22 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck
Cc: linux-s390, Joerg Roedel, KVM, Michael Tsirkin, benh,
Sebastian Ott, virtualization, Martin Schwidefsky, Paolo Bonzini,
dwmw2, Christoph Hellwig
In-Reply-To: <563B2275.3010406@de.ibm.com>
On 11/05/2015 01:33 AM, Christian Borntraeger wrote:
> Am 03.11.2015 um 13:26 schrieb Cornelia Huck:
>> On Tue, 3 Nov 2015 12:54:39 +0100
>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>>
>>> As virtio-ccw now has dma ops, we can no longer default to the PCI ones.
>>> Make use of dev_archdata to keep the dma_ops per device. The pci devices
>>> now use that to override the default, and the default is changed to use
>>> the noop ops for everything that is not PCI. To compile without PCI
>>> support we also have to enable the DMA api with virtio.
>>
>> Not only with virtio, but generally, right?
>
> Yes, will update the patch description.
>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> Reviewed-by: Joerg Roedel <jroedel@suse.de>
>>> Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
>>> ---
>>> arch/s390/Kconfig | 3 ++-
>>> arch/s390/include/asm/device.h | 6 +++++-
>>> arch/s390/include/asm/dma-mapping.h | 6 ++++--
>>> arch/s390/pci/pci.c | 1 +
>>> arch/s390/pci/pci_dma.c | 4 ++--
>>> 5 files changed, 14 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
>>> index 1d57000..04f0e02 100644
>>> --- a/arch/s390/Kconfig
>>> +++ b/arch/s390/Kconfig
>>> @@ -113,6 +113,7 @@ config S390
>>> select GENERIC_FIND_FIRST_BIT
>>> select GENERIC_SMP_IDLE_THREAD
>>> select GENERIC_TIME_VSYSCALL
>>> + select HAS_DMA
>>> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
>>> select HAVE_ARCH_AUDITSYSCALL
>>> select HAVE_ARCH_EARLY_PFN_TO_NID
>>> @@ -124,6 +125,7 @@ config S390
>>> select HAVE_CMPXCHG_DOUBLE
>>> select HAVE_CMPXCHG_LOCAL
>>> select HAVE_DEBUG_KMEMLEAK
>>> + select HAVE_DMA_ATTRS
>>> select HAVE_DYNAMIC_FTRACE
>>> select HAVE_DYNAMIC_FTRACE_WITH_REGS
>>> select HAVE_FTRACE_MCOUNT_RECORD
>>> @@ -580,7 +582,6 @@ config QDIO
>>>
>>> menuconfig PCI
>>> bool "PCI support"
>>> - select HAVE_DMA_ATTRS
>>> select PCI_MSI
>>> help
>>> Enable PCI support.
>>
>> Hm. Further down in this file, there's
>>
>> config HAS_DMA
>> def_bool PCI
>> select HAVE_DMA_API_DEBUG
>>
>> Should we maybe select HAVE_DMA_API_DEBUG above, drop the HAS_DMA
>> config option and rely on not defining NO_DMA instead?
>
> Hmm, yes. That would simplify things a lot. Right now we include
> lib/Kconfig (which defines HAS_DMA) and define it ourselfes in
> arch/s390/Kconfig. WHoever comes first wins. Adding a select statement
> would make this even more complicated.
>
> Andy, I will simply send you a respin of this patch.
>
I'm slightly concerned that I'm going to screw this all up and apply the
wrong version. Could you resend the whole series with git format-patch
-vN for some appropriate N (or similar)?
Thanks,
Andy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox