* [PATCH v2 09/11] events/x86: Define SCI virtual interrupt
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
PVH guests do not have IOAPIC which typically generates an SCI. For
those guests SCI will be provided as a virtual interrupt.
We also move VIRQ_MCA definition out of xen-mca.h to
keep all x86-specific VIRQ_ARCH_* in one place.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
xen/include/asm-x86/event.h | 3 ++-
xen/include/public/arch-x86/xen-mca.h | 2 --
xen/include/public/arch-x86/xen.h | 3 +++
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index a82062e..9cad8e3 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -38,9 +38,10 @@ static inline void local_event_delivery_enable(void)
vcpu_info(current, evtchn_upcall_mask) = 0;
}
-/* No arch specific virq definition now. Default to global. */
static inline int arch_virq_is_global(uint32_t virq)
{
+ if ( virq == VIRQ_SCI )
+ return 0;
return 1;
}
diff --git a/xen/include/public/arch-x86/xen-mca.h b/xen/include/public/arch-x86/xen-mca.h
index a97e821..b76c53c 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -91,8 +91,6 @@
#ifndef __ASSEMBLY__
-#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
-
/*
* Machine Check Architecure:
* structs are read-only and used to report all kinds of
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 350bc66..4750ba7 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -296,6 +296,9 @@ struct xen_arch_domainconfig {
};
#endif
+#define VIRQ_MCA VIRQ_ARCH_0 /* G. (DOM0) Machine Check Architecture */
+#define VIRQ_SCI VIRQ_ARCH_1 /* V. (PVH) ACPI interrupt */
+
#endif /* !__ASSEMBLY__ */
/*
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 08/11] pvh/acpi: Handle ACPI accesses for PVH guests
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, Paul Durrant, jbeulich,
Boris Ostrovsky, roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
CC: Paul Durrant <paul.durrant@citrix.com>
---
Changes in v2:
* Use 'true/false' values for bools
xen/arch/x86/hvm/ioreq.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e6ff48f..3ef01cf 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1383,6 +1383,78 @@ static int hvm_access_cf8(
static int acpi_ioaccess(
int dir, unsigned int port, unsigned int bytes, uint32_t *val)
{
+ unsigned int i;
+ unsigned int bits = bytes * 8;
+ unsigned int idx = port & 3;
+ uint8_t *reg = NULL;
+ bool is_cpu_map = false;
+ struct domain *currd = current->domain;
+
+ BUILD_BUG_ON((ACPI_PM1A_EVT_BLK_LEN != 4) ||
+ (ACPI_GPE0_BLK_LEN_V1 != 4));
+
+ if ( has_ioreq_cpuhp(currd) )
+ return X86EMUL_UNHANDLEABLE;
+
+ switch (port)
+ {
+ case ACPI_PM1A_EVT_BLK_ADDRESS_V1 ...
+ (ACPI_PM1A_EVT_BLK_ADDRESS_V1 + ACPI_PM1A_EVT_BLK_LEN - 1):
+ reg = currd->arch.hvm_domain.acpi_io.pm1a;
+ break;
+ case ACPI_GPE0_BLK_ADDRESS_V1 ...
+ (ACPI_GPE0_BLK_ADDRESS_V1 + ACPI_GPE0_BLK_LEN_V1 - 1):
+ reg = currd->arch.hvm_domain.acpi_io.gpe;
+ break;
+ case ACPI_CPU_MAP ... (ACPI_CPU_MAP + ACPI_CPU_MAP_LEN - 1):
+ is_cpu_map = true;
+ break;
+ default:
+ return X86EMUL_UNHANDLEABLE;
+ }
+
+ if ( bytes == 0 )
+ return X86EMUL_OKAY;
+
+ if ( dir == IOREQ_READ )
+ {
+ *val &= ~((1U << bits) - 1);
+
+ if ( is_cpu_map )
+ {
+ unsigned int first_bit, last_bit;
+
+ first_bit = (port - ACPI_CPU_MAP) * 8;
+ last_bit = min(currd->arch.avail_vcpus, first_bit + bits);
+ for ( i = first_bit; i < last_bit; i++ )
+ *val |= (1U << (i - first_bit));
+ }
+ else
+ memcpy(val, ®[idx], bytes);
+ }
+ else
+ {
+ if ( is_cpu_map )
+ /*
+ * CPU map is only read by DSDT's PRSC method and should never
+ * be written by a guest.
+ */
+ return X86EMUL_UNHANDLEABLE;
+
+ /* Write either status or enable reegister. */
+ if ( (bytes > 2) || ((bytes == 2) && (port & 1)) )
+ return X86EMUL_UNHANDLEABLE;
+
+ if ( idx < 2 ) /* status, write 1 to clear. */
+ {
+ reg[idx] &= ~(*val & 0xff);
+ if ( bytes == 2 )
+ reg[idx + 1] &= ~((*val >> 8) & 0xff);
+ }
+ else /* enable */
+ memcpy(®[idx], val, bytes);
+ }
+
return X86EMUL_OKAY;
}
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, Paul Durrant, jbeulich,
Boris Ostrovsky, roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
PVH guests will have ACPI accesses emulated by the hypervisor
as opposed to QEMU (as is the case for HVM guests)
Support for IOREQ server emulation of CPU hotplug is indicated
by XEN_X86_EMU_IOREQ_CPUHP flag.
Logic for the handler will be provided by a later patch.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
CC: Paul Durrant <paul.durrant@citrix.com>
---
Changes in v2:
* Introduce XEN_X86_EMU_IOREQ_CPUHP, don't set HVM_PARAM_NR_IOREQ_SERVER_PAGES
for PVH guests
* Register IO hadler for PVH from hvm_ioreq_init()
xen/arch/x86/hvm/ioreq.c | 18 ++++++++++++++++++
xen/include/asm-x86/domain.h | 2 ++
xen/include/public/arch-x86/xen.h | 5 ++++-
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index d2245e2..e6ff48f 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1380,6 +1380,12 @@ static int hvm_access_cf8(
return X86EMUL_UNHANDLEABLE;
}
+static int acpi_ioaccess(
+ int dir, unsigned int port, unsigned int bytes, uint32_t *val)
+{
+ return X86EMUL_OKAY;
+}
+
void hvm_ioreq_init(struct domain *d)
{
spin_lock_init(&d->arch.hvm_domain.ioreq_server.lock);
@@ -1387,6 +1393,18 @@ void hvm_ioreq_init(struct domain *d)
if ( !is_pvh_domain(d) )
register_portio_handler(d, 0xcf8, 4, hvm_access_cf8);
+
+ if ( !has_ioreq_cpuhp(d) )
+ {
+ /* Online CPU map, see DSDT's PRST region. */
+ register_portio_handler(d, ACPI_CPU_MAP,
+ ACPI_CPU_MAP_LEN, acpi_ioaccess);
+
+ register_portio_handler(d, ACPI_GPE0_BLK_ADDRESS_V1,
+ ACPI_GPE0_BLK_LEN_V1, acpi_ioaccess);
+ register_portio_handler(d, ACPI_PM1A_EVT_BLK_ADDRESS_V1,
+ ACPI_PM1A_EVT_BLK_LEN, acpi_ioaccess);
+ }
}
/*
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index a279e4a..7aa736c 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -431,6 +431,8 @@ struct arch_domain
#define has_vvga(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
#define has_viommu(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
#define has_vpit(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
+#define has_ioreq_cpuhp(d) (!!((d)->arch.emulation_flags & \
+ XEN_X86_EMU_IOREQ_CPUHP))
#define has_arch_pdevs(d) (!list_empty(&(d)->arch.pdev_list))
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index cdd93c1..350bc66 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -283,12 +283,15 @@ struct xen_arch_domainconfig {
#define XEN_X86_EMU_IOMMU (1U<<_XEN_X86_EMU_IOMMU)
#define _XEN_X86_EMU_PIT 8
#define XEN_X86_EMU_PIT (1U<<_XEN_X86_EMU_PIT)
+#define _XEN_X86_EMU_IOREQ_CPUHP 9
+#define XEN_X86_EMU_IOREQ_CPUHP (1U<<_XEN_X86_EMU_IOREQ_CPUHP)
#define XEN_X86_EMU_ALL (XEN_X86_EMU_LAPIC | XEN_X86_EMU_HPET | \
XEN_X86_EMU_PM | XEN_X86_EMU_RTC | \
XEN_X86_EMU_IOAPIC | XEN_X86_EMU_PIC | \
XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU | \
- XEN_X86_EMU_PIT)
+ XEN_X86_EMU_PIT | \
+ XEN_X86_EMU_IOREQ_CPUHP)
uint32_t emulation_flags;
};
#endif
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 06/11] acpi: PVH guests need _E02 method
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
This is the method that will get invoked on an SCI.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
tools/libacpi/mk_dsdt.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 2b8234d..780783e 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -282,11 +282,6 @@ int main(int argc, char **argv)
pop_block();
- if (dm_version == QEMU_NONE) {
- pop_block();
- return 0;
- }
-
/* Define GPE control method. */
push_block("Scope", "\\_GPE");
push_block("Method",
@@ -294,6 +289,11 @@ int main(int argc, char **argv)
stmt("\\_SB.PRSC ()", NULL);
pop_block();
pop_block();
+
+ if (dm_version == QEMU_NONE) {
+ pop_block();
+ return 0;
+ }
/**** Processor end ****/
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 05/11] acpi: Power and Sleep ACPI buttons are not emulated for PVH guests
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v2:
* HVM guests continue having the buttons
tools/firmware/hvmloader/util.c | 3 ++-
tools/libacpi/build.c | 2 ++
tools/libacpi/libacpi.h | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1d78973..a3f12fe 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -949,7 +949,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
config->table_flags |= ACPI_HAS_SSDT_S4;
config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC |
- ACPI_HAS_WAET | ACPI_HAS_PMTIMER);
+ ACPI_HAS_WAET | ACPI_HAS_PMTIMER |
+ ACPI_HAS_BUTTONS);
config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 58822d3..5c4a818 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -579,6 +579,8 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
Fadt.pm_tmr_blk = 0;
memset(&Fadt.x_pm_tmr_blk, 0, sizeof(Fadt.x_pm_tmr_blk));
}
+ if ( !(config->table_flags & ACPI_HAS_BUTTONS) )
+ Fadt.flags |= (ACPI_PWR_BUTTON | ACPI_SLP_BUTTON);
memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
fadt->dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index bda692e..dd6ef8b 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -31,6 +31,7 @@
#define ACPI_HAS_IOAPIC (1<<8)
#define ACPI_HAS_WAET (1<<9)
#define ACPI_HAS_PMTIMER (1<<10)
+#define ACPI_HAS_BUTTONS (1<<11)
struct xen_vmemrange;
struct acpi_numa {
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 04/11] acpi: Make pmtimer optional in FADT
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
PM timer is not supported by PVH guests.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
tools/firmware/hvmloader/util.c | 3 ++-
tools/libacpi/build.c | 5 +++++
tools/libacpi/libacpi.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 6e0cfe7..1d78973 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -948,7 +948,8 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
config->table_flags |= ACPI_HAS_SSDT_S4;
- config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
+ config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC |
+ ACPI_HAS_WAET | ACPI_HAS_PMTIMER);
config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 47dae01..58822d3 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -574,6 +574,11 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
fadt = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_fadt), 16);
if (!fadt) goto oom;
+ if ( !(config->table_flags & ACPI_HAS_PMTIMER) )
+ {
+ Fadt.pm_tmr_blk = 0;
+ memset(&Fadt.x_pm_tmr_blk, 0, sizeof(Fadt.x_pm_tmr_blk));
+ }
memcpy(fadt, &Fadt, sizeof(struct acpi_20_fadt));
fadt->dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
fadt->x_dsdt = ctxt->mem_ops.v2p(ctxt, dsdt);
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 1d388f9..bda692e 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -30,6 +30,7 @@
#define ACPI_HAS_TCPA (1<<7)
#define ACPI_HAS_IOAPIC (1<<8)
#define ACPI_HAS_WAET (1<<9)
+#define ACPI_HAS_PMTIMER (1<<10)
struct xen_vmemrange;
struct acpi_numa {
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH] webkitgtk: Add an option to disable opengl support
From: Carlos Alberto Lopez Perez @ 2016-11-09 14:39 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Carlos Alberto Lopez Perez <clopez@igalia.com>
---
meta/recipes-sato/webkit/webkitgtk_2.14.1.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb b/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
index 69c9f11..d6d9c14 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.14.1.bb
@@ -41,7 +41,7 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt libidn gnutls \
"
PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'wayland' ,d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl', '' ,d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl opengl', '' ,d)} \
enchant \
libsecret \
"
@@ -53,6 +53,7 @@ PACKAGECONFIG[enchant] = "-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant
PACKAGECONFIG[gtk2] = "-DENABLE_PLUGIN_PROCESS_GTK2=ON,-DENABLE_PLUGIN_PROCESS_GTK2=OFF,gtk+"
PACKAGECONFIG[gles2] = "-DENABLE_GLES2=ON,-DENABLE_GLES2=OFF,virtual/libgles2"
PACKAGECONFIG[webgl] = "-DENABLE_WEBGL=ON,-DENABLE_WEBGL=OFF,virtual/libgl"
+PACKAGECONFIG[opengl] = "-DENABLE_OPENGL=ON,-DENABLE_OPENGL=OFF,virtual/libgl"
PACKAGECONFIG[libsecret] = "-DENABLE_CREDENTIAL_STORAGE=ON,-DENABLE_CREDENTIAL_STORAGE=OFF,libsecret"
PACKAGECONFIG[libhyphen] = "-DUSE_LIBHYPHEN=ON,-DUSE_LIBHYPHEN=OFF,libhyphen"
--
2.1.4
^ permalink raw reply related
* [PATCH v2 03/11] pvh: Set online VCPU map to avail_vcpus
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT.
With ACPI-based CPU hotplug we only want VCPUs that are started by
the guest to be marked as such. Remaining VCPUs will be set to
"enable" by AML code during hotplug.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
Changes in v2:
* Clarified in the commit message that it's AML that updates MADT
tools/libxl/libxl_x86_acpi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index ff0e2df..949f555 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -98,7 +98,7 @@ static int init_acpi_config(libxl__gc *gc,
uint32_t domid = dom->guest_domid;
xc_dominfo_t info;
struct hvm_info_table *hvminfo;
- int i, rc = 0;
+ int rc = 0;
config->dsdt_anycpu = config->dsdt_15cpu = dsdt_pvh;
config->dsdt_anycpu_len = config->dsdt_15cpu_len = dsdt_pvh_len;
@@ -144,8 +144,8 @@ static int init_acpi_config(libxl__gc *gc,
hvminfo->nr_vcpus = info.max_vcpu_id + 1;
}
- for (i = 0; i < hvminfo->nr_vcpus; i++)
- hvminfo->vcpu_online[i / 8] |= 1 << (i & 7);
+ memcpy(hvminfo->vcpu_online, b_info->avail_vcpus.map,
+ b_info->avail_vcpus.size);
config->hvminfo = hvminfo;
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 02/11] acpi: Define ACPI IO registers for PVH guests
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, Julien Grall, Paul Durrant,
jbeulich, Boris Ostrovsky, roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
ACPI hotplug-related IO accesses (to GPE0 block) are handled
by qemu for HVM guests. Since PVH guests don't have qemu these
accesses will need to be procesed by the hypervisor.
Because ACPI event model expects pm1a block to be present we
need to have the hypervisor emulate it as well.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
CC: Julien Grall <julien.grall@arm.com>
CC: Paul Durrant <paul.durrant@citrix.com>
---
Changes in v2:
* Added public macros for ACPI CPU bitmap (at 0xaf00). Note: PRST
region shrinks from 32 bytes to 16 (when 128 VCPUs are
supported).
tools/libacpi/mk_dsdt.c | 4 +++-
tools/libacpi/static_tables.c | 28 +++++++++++-----------------
xen/include/asm-x86/hvm/domain.h | 6 ++++++
xen/include/public/arch-arm.h | 11 ++++++++---
xen/include/public/hvm/ioreq.h | 13 +++++++++++++
5 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 4ae68bc..2b8234d 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -19,6 +19,7 @@
#include <stdbool.h>
#if defined(__i386__) || defined(__x86_64__)
#include <xen/hvm/hvm_info_table.h>
+#include <xen/hvm/ioreq.h>
#elif defined(__aarch64__)
#include <xen/arch-arm.h>
#endif
@@ -244,7 +245,8 @@ int main(int argc, char **argv)
#endif
/* Operation Region 'PRST': bitmask of online CPUs. */
- stmt("OperationRegion", "PRST, SystemIO, 0xaf00, 32");
+ stmt("OperationRegion", "PRST, SystemIO, 0x%x, %d",
+ ACPI_CPU_MAP, ACPI_CPU_MAP_LEN);
push_block("Field", "PRST, ByteAcc, NoLock, Preserve");
indent(); printf("PRS, %u\n", max_cpus);
pop_block();
diff --git a/tools/libacpi/static_tables.c b/tools/libacpi/static_tables.c
index 617bf68..413abcc 100644
--- a/tools/libacpi/static_tables.c
+++ b/tools/libacpi/static_tables.c
@@ -20,6 +20,8 @@
* Firmware ACPI Control Structure (FACS).
*/
+#define ACPI_REG_BIT_OFFSET 0
+
struct acpi_20_facs Facs = {
.signature = ACPI_2_0_FACS_SIGNATURE,
.length = sizeof(struct acpi_20_facs),
@@ -30,14 +32,6 @@ struct acpi_20_facs Facs = {
/*
* Fixed ACPI Description Table (FADT).
*/
-
-#define ACPI_PM1A_EVT_BLK_BIT_WIDTH 0x20
-#define ACPI_PM1A_EVT_BLK_BIT_OFFSET 0x00
-#define ACPI_PM1A_CNT_BLK_BIT_WIDTH 0x10
-#define ACPI_PM1A_CNT_BLK_BIT_OFFSET 0x00
-#define ACPI_PM_TMR_BLK_BIT_WIDTH 0x20
-#define ACPI_PM_TMR_BLK_BIT_OFFSET 0x00
-
struct acpi_20_fadt Fadt = {
.header = {
.signature = ACPI_2_0_FADT_SIGNATURE,
@@ -56,9 +50,9 @@ struct acpi_20_fadt Fadt = {
.pm1a_cnt_blk = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
.pm_tmr_blk = ACPI_PM_TMR_BLK_ADDRESS_V1,
.gpe0_blk = ACPI_GPE0_BLK_ADDRESS_V1,
- .pm1_evt_len = ACPI_PM1A_EVT_BLK_BIT_WIDTH / 8,
- .pm1_cnt_len = ACPI_PM1A_CNT_BLK_BIT_WIDTH / 8,
- .pm_tmr_len = ACPI_PM_TMR_BLK_BIT_WIDTH / 8,
+ .pm1_evt_len = ACPI_PM1A_EVT_BLK_LEN,
+ .pm1_cnt_len = ACPI_PM1A_CNT_BLK_LEN,
+ .pm_tmr_len = ACPI_PM_TMR_BLK_LEN,
.gpe0_blk_len = ACPI_GPE0_BLK_LEN_V1,
.p_lvl2_lat = 0x0fff, /* >100, means we do not support C2 state */
@@ -79,22 +73,22 @@ struct acpi_20_fadt Fadt = {
.x_pm1a_evt_blk = {
.address_space_id = ACPI_SYSTEM_IO,
- .register_bit_width = ACPI_PM1A_EVT_BLK_BIT_WIDTH,
- .register_bit_offset = ACPI_PM1A_EVT_BLK_BIT_OFFSET,
+ .register_bit_width = ACPI_PM1A_EVT_BLK_LEN * 8,
+ .register_bit_offset = ACPI_REG_BIT_OFFSET,
.address = ACPI_PM1A_EVT_BLK_ADDRESS_V1,
},
.x_pm1a_cnt_blk = {
.address_space_id = ACPI_SYSTEM_IO,
- .register_bit_width = ACPI_PM1A_CNT_BLK_BIT_WIDTH,
- .register_bit_offset = ACPI_PM1A_CNT_BLK_BIT_OFFSET,
+ .register_bit_width = ACPI_PM1A_CNT_BLK_LEN * 8,
+ .register_bit_offset = ACPI_REG_BIT_OFFSET,
.address = ACPI_PM1A_CNT_BLK_ADDRESS_V1,
},
.x_pm_tmr_blk = {
.address_space_id = ACPI_SYSTEM_IO,
- .register_bit_width = ACPI_PM_TMR_BLK_BIT_WIDTH,
- .register_bit_offset = ACPI_PM_TMR_BLK_BIT_OFFSET,
+ .register_bit_width = ACPI_PM_TMR_BLK_LEN * 8,
+ .register_bit_offset = ACPI_REG_BIT_OFFSET,
.address = ACPI_PM_TMR_BLK_ADDRESS_V1,
}
};
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index f34d784..f492a2b 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -87,6 +87,12 @@ struct hvm_domain {
} ioreq_server;
struct hvm_ioreq_server *default_ioreq_server;
+ /* PVH guests */
+ struct {
+ uint8_t pm1a[ACPI_PM1A_EVT_BLK_LEN];
+ uint8_t gpe[ACPI_GPE0_BLK_LEN_V1];
+ } acpi_io;
+
/* Cached CF8 for guest PCI config cycles */
uint32_t pci_cf8;
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb..b793774 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -383,6 +383,9 @@ typedef uint64_t xen_callback_t;
* should instead use the FDT.
*/
+/* Current supported guest VCPUs */
+#define GUEST_MAX_VCPUS 128
+
/* Physical Address Space */
/*
@@ -410,6 +413,11 @@ typedef uint64_t xen_callback_t;
#define GUEST_ACPI_BASE 0x20000000ULL
#define GUEST_ACPI_SIZE 0x02000000ULL
+/* Location of online VCPU bitmap. */
+#define ACPI_CPU_MAP 0xaf00
+#define ACPI_CPU_MAP_LEN ((GUEST_MAX_VCPUS / 8) + \
+ ((GUEST_MAX_VCPUS & 7) ? 1 : 0))
+
/*
* 16MB == 4096 pages reserved for guest to use as a region to map its
* grant table in.
@@ -435,9 +443,6 @@ typedef uint64_t xen_callback_t;
#define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
#define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
-/* Current supported guest VCPUs */
-#define GUEST_MAX_VCPUS 128
-
/* Interrupts */
#define GUEST_TIMER_VIRT_PPI 27
#define GUEST_TIMER_PHYS_S_PPI 29
diff --git a/xen/include/public/hvm/ioreq.h b/xen/include/public/hvm/ioreq.h
index 2e5809b..e3fa704 100644
--- a/xen/include/public/hvm/ioreq.h
+++ b/xen/include/public/hvm/ioreq.h
@@ -24,6 +24,8 @@
#ifndef _IOREQ_H_
#define _IOREQ_H_
+#include "hvm_info_table.h" /* HVM_MAX_VCPUS */
+
#define IOREQ_READ 1
#define IOREQ_WRITE 0
@@ -124,6 +126,17 @@ typedef struct buffered_iopage buffered_iopage_t;
#define ACPI_GPE0_BLK_ADDRESS ACPI_GPE0_BLK_ADDRESS_V0
#define ACPI_GPE0_BLK_LEN ACPI_GPE0_BLK_LEN_V0
+#define ACPI_PM1A_EVT_BLK_LEN 0x04
+#define ACPI_PM1A_CNT_BLK_LEN 0x02
+#define ACPI_PM_TMR_BLK_LEN 0x04
+
+/* Location of online VCPU bitmap. */
+#define ACPI_CPU_MAP 0xaf00
+#define ACPI_CPU_MAP_LEN ((HVM_MAX_VCPUS / 8) + \
+ ((HVM_MAX_VCPUS & 7) ? 1 : 0))
+#if ACPI_CPU_MAP + ACPI_CPU_MAP_LEN >= ACPI_GPE0_BLK_ADDRESS_V1
+#error "ACPI_CPU_MAP is too big"
+#endif
#endif /* _IOREQ_H_ */
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
In-Reply-To: <1478702399-14538-1-git-send-email-boris.ostrovsky@oracle.com>
This domctl is called when a VCPU is hot-(un)plugged to a guest (via
'xl vcpu-set'). While this currently is only intended to be needed by
PVH guests we will call this domctl for all (x86) guests for consistency.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
Changes in v2:
* Added comment in arch_do_domctl() stating that the domctl is only required
for PVH guests
tools/flask/policy/modules/dom0.te | 2 +-
tools/flask/policy/modules/xen.if | 4 ++--
tools/libxc/include/xenctrl.h | 5 +++++
tools/libxc/xc_dom_x86.c | 11 +++++++++++
tools/libxl/libxl.c | 10 +++++++++-
tools/libxl/libxl_arch.h | 4 ++++
tools/libxl/libxl_arm.c | 6 ++++++
tools/libxl/libxl_dom.c | 7 +++++++
tools/libxl/libxl_x86.c | 6 ++++++
xen/arch/x86/domctl.c | 17 +++++++++++++++++
xen/include/asm-x86/domain.h | 6 ++++++
xen/include/public/domctl.h | 9 +++++++++
xen/xsm/flask/hooks.c | 3 +++
xen/xsm/flask/policy/access_vectors | 2 ++
14 files changed, 88 insertions(+), 4 deletions(-)
diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 2d982d9..fd60c39 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -38,7 +38,7 @@ allow dom0_t dom0_t:domain {
};
allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
- get_vnumainfo psr_cmt_op psr_cat_op
+ get_vnumainfo psr_cmt_op psr_cat_op set_avail_vcpus
};
allow dom0_t dom0_t:resource { add remove };
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index eb646f5..afbedc2 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -52,7 +52,7 @@ define(`create_domain_common', `
settime setdomainhandle getvcpucontext };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
- psr_cmt_op psr_cat_op soft_reset };
+ psr_cmt_op psr_cat_op soft_reset set_avail_vcpus};
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op updatemp };
@@ -85,7 +85,7 @@ define(`manage_domain', `
getaddrsize pause unpause trigger shutdown destroy
setaffinity setdomainmaxmem getscheduler resume
setpodtarget getpodtarget };
- allow $1 $2:domain2 set_vnumainfo;
+ allow $1 $2:domain2 { set_vnumainfo set_avail_vcpus };
')
# migrate_domain_out(priv, target)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2c83544..49e9b9f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1256,6 +1256,11 @@ int xc_domain_getvnuma(xc_interface *xch,
int xc_domain_soft_reset(xc_interface *xch,
uint32_t domid);
+int xc_domain_set_avail_vcpus(xc_interface *xch,
+ uint32_t domid,
+ unsigned int num_vcpus);
+
+
#if defined(__i386__) || defined(__x86_64__)
/*
* PC BIOS standard E820 types and structure.
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0eab8a7..7fcdee1 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -125,6 +125,17 @@ const char *xc_domain_get_native_protocol(xc_interface *xch,
return protocol;
}
+int xc_domain_set_avail_vcpus(xc_interface *xch,
+ uint32_t domid,
+ unsigned int num_vcpus)
+{
+ DECLARE_DOMCTL;
+ domctl.cmd = XEN_DOMCTL_set_avail_vcpus;
+ domctl.domain = (domid_t)domid;
+ domctl.u.avail_vcpus.num = num_vcpus;
+ return do_domctl(xch, &domctl);
+}
+
static int count_pgtables(struct xc_dom_image *dom, xen_vaddr_t from,
xen_vaddr_t to, xen_pfn_t pfn)
{
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 33c5e4c..9b94413 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5148,11 +5148,12 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
case LIBXL_DOMAIN_TYPE_HVM:
switch (libxl__device_model_version_running(gc, domid)) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
- case LIBXL_DEVICE_MODEL_VERSION_NONE:
rc = libxl__set_vcpuonline_xenstore(gc, domid, cpumap, &info);
break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
rc = libxl__set_vcpuonline_qmp(gc, domid, cpumap, &info);
+ /* fallthrough */
+ case LIBXL_DEVICE_MODEL_VERSION_NONE:
break;
default:
rc = ERROR_INVAL;
@@ -5164,6 +5165,13 @@ int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap *cpumap)
default:
rc = ERROR_INVAL;
}
+
+ if (!rc) {
+ rc = libxl__arch_set_vcpuonline(ctx, domid, maxcpus);
+ if (rc)
+ LOG(ERROR, "Couldn't set available vcpu count");
+ }
+
out:
libxl_dominfo_dispose(&info);
GC_FREE;
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc60..33b5e12 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -71,6 +71,10 @@ int libxl__arch_extra_memory(libxl__gc *gc,
const libxl_domain_build_info *info,
uint64_t *out);
+_hidden
+int libxl__arch_set_vcpuonline(libxl_ctx *ctx, uint32_t domid,
+ unsigned int vcpu_num);
+
#if defined(__i386__) || defined(__x86_64__)
#define LAPIC_BASE_ADDRESS 0xfee00000
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d842d88..18c79b0 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1065,6 +1065,12 @@ void libxl__arch_domain_build_info_acpi_setdefault(
libxl_defbool_setdefault(&b_info->acpi, false);
}
+int libxl__arch_set_vcpuonline(libxl_ctx *ctx, uint32_t domid,
+ unsigned int vcpu_num)
+{
+ return 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d519c8d..e6e94bb 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -309,6 +309,13 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
return ERROR_FAIL;
}
+ rc = libxl__arch_set_vcpuonline(ctx, domid,
+ libxl_bitmap_count_set(&info->avail_vcpus));
+ if (rc) {
+ LOG(ERROR, "Couldn't set available vcpu count (error %d)", rc);
+ return ERROR_FAIL;
+ }
+
/*
* Check if the domain has any CPU or node affinity already. If not, try
* to build up the latter via automatic NUMA placement. In fact, in case
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index e1844c8..3a5264d 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -588,6 +588,12 @@ void libxl__arch_domain_build_info_acpi_setdefault(
libxl_defbool_setdefault(&b_info->acpi, true);
}
+int libxl__arch_set_vcpuonline(libxl_ctx *ctx, uint32_t domid,
+ unsigned int vcpu_num)
+{
+ return xc_domain_set_avail_vcpus(ctx->xch, domid, vcpu_num);
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2a2fe04..b736d4c 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1430,6 +1430,23 @@ long arch_do_domctl(
}
break;
+ case XEN_DOMCTL_set_avail_vcpus:
+ {
+ unsigned int num = domctl->u.avail_vcpus.num;
+
+ /*
+ * This is currently only needed by PVH guests (but
+ * any guest is free to make this call).
+ */
+ ret = -EINVAL;
+ if ( num > d->max_vcpus )
+ break;
+
+ d->arch.avail_vcpus = num;
+ ret = 0;
+ break;
+ }
+
default:
ret = iommu_do_domctl(domctl, d, u_domctl);
break;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f6a40eb..a279e4a 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -414,6 +414,12 @@ struct arch_domain
/* Emulated devices enabled bitmap. */
uint32_t emulation_flags;
+
+ /*
+ * Number of VCPUs that were online during guest creation
+ * plus/minus any hot-(un)plugged VCPUs.
+ */
+ unsigned int avail_vcpus;
} __cacheline_aligned;
#define has_vlapic(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_LAPIC))
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 177319d..f114645 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1010,6 +1010,13 @@ struct xen_domctl_vcpu_msrs {
};
typedef struct xen_domctl_vcpu_msrs xen_domctl_vcpu_msrs_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpu_msrs_t);
+
+/* XEN_DOMCTL_avail_vcpus */
+struct xen_domctl_avail_vcpus {
+ uint32_t num; /* available number of vcpus */
+};
+typedef struct xen_domctl_avail_vcpus xen_domctl_avail_vcpus_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_avail_vcpus_t);
#endif
/* XEN_DOMCTL_setvnumainfo: specifies a virtual NUMA topology for the guest */
@@ -1221,6 +1228,7 @@ struct xen_domctl {
#define XEN_DOMCTL_monitor_op 77
#define XEN_DOMCTL_psr_cat_op 78
#define XEN_DOMCTL_soft_reset 79
+#define XEN_DOMCTL_set_avail_vcpus 80
#define XEN_DOMCTL_gdbsx_guestmemio 1000
#define XEN_DOMCTL_gdbsx_pausevcpu 1001
#define XEN_DOMCTL_gdbsx_unpausevcpu 1002
@@ -1269,6 +1277,7 @@ struct xen_domctl {
struct xen_domctl_cpuid cpuid;
struct xen_domctl_vcpuextstate vcpuextstate;
struct xen_domctl_vcpu_msrs vcpu_msrs;
+ struct xen_domctl_avail_vcpus avail_vcpus;
#endif
struct xen_domctl_set_access_required access_required;
struct xen_domctl_audit_p2m audit_p2m;
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 177c11f..377549a 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -748,6 +748,9 @@ static int flask_domctl(struct domain *d, int cmd)
case XEN_DOMCTL_soft_reset:
return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SOFT_RESET);
+ case XEN_DOMCTL_set_avail_vcpus:
+ return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_AVAIL_VCPUS);
+
default:
return avc_unknown_permission("domctl", cmd);
}
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 49c9a9e..f8a5e6c 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -244,6 +244,8 @@ class domain2
mem_sharing
# XEN_DOMCTL_psr_cat_op
psr_cat_op
+# XEN_DOMCTL_set_avail_vcpus
+ set_avail_vcpus
}
# Similar to class domain, but primarily contains domctls related to HVM domains
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* [PATCH v2 00/11] PVH VCPU hotplug support
From: Boris Ostrovsky @ 2016-11-09 14:39 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, andrew.cooper3, ian.jackson, jbeulich, Boris Ostrovsky,
roger.pau
This series adds support for ACPI-based VCPU hotplug for unprivileged
PVH guests.
New XEN_DOMCTL_set_avail_vcpus is introduced and is called during
guest creation and in response to 'xl vcpu-set' command. This domctl
updates GPE0's status and enable registers and sends an SCI to the
guest using (newly added) VIRQ_SCI.
Main changes in V2:
* Add XEN_X86_EMU_IOREQ_CPUHP flag to indicate need to handle
ACPI accesses in hypervisor
* Add ACPI_CPU_MAP[_LEN] for 0xafee address block
Boris Ostrovsky (11):
x86/domctl: Add XEN_DOMCTL_set_avail_vcpus
acpi: Define ACPI IO registers for PVH guests
pvh: Set online VCPU map to avail_vcpus
acpi: Make pmtimer optional in FADT
acpi: Power and Sleep ACPI buttons are not emulated for PVH guests
acpi: PVH guests need _E02 method
pvh/ioreq: Install handlers for ACPI-related PVH IO accesses
pvh/acpi: Handle ACPI accesses for PVH guests
events/x86: Define SCI virtual interrupt
pvh: Send an SCI on VCPU hotplug event
docs: Describe PVHv2's VCPU hotplug procedure
docs/misc/hvmlite.markdown | 12 +++++
tools/firmware/hvmloader/util.c | 4 +-
tools/flask/policy/modules/dom0.te | 2 +-
tools/flask/policy/modules/xen.if | 4 +-
tools/libacpi/build.c | 7 +++
tools/libacpi/libacpi.h | 2 +
tools/libacpi/mk_dsdt.c | 14 +++---
tools/libacpi/static_tables.c | 28 +++++------
tools/libxc/include/xenctrl.h | 5 ++
tools/libxc/xc_dom_x86.c | 11 +++++
tools/libxl/libxl.c | 10 +++-
tools/libxl/libxl_arch.h | 4 ++
tools/libxl/libxl_arm.c | 6 +++
tools/libxl/libxl_dom.c | 7 +++
tools/libxl/libxl_x86.c | 6 +++
tools/libxl/libxl_x86_acpi.c | 6 +--
xen/arch/x86/domctl.c | 29 +++++++++++
xen/arch/x86/hvm/ioreq.c | 90 +++++++++++++++++++++++++++++++++++
xen/include/asm-x86/domain.h | 8 ++++
xen/include/asm-x86/event.h | 3 +-
xen/include/asm-x86/hvm/domain.h | 6 +++
xen/include/public/arch-arm.h | 11 +++--
xen/include/public/arch-x86/xen-mca.h | 2 -
xen/include/public/arch-x86/xen.h | 8 +++-
xen/include/public/domctl.h | 9 ++++
xen/include/public/hvm/ioreq.h | 13 +++++
xen/xsm/flask/hooks.c | 3 ++
xen/xsm/flask/policy/access_vectors | 2 +
28 files changed, 274 insertions(+), 38 deletions(-)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Arnaldo Carvalho de Melo @ 2016-11-09 14:39 UTC (permalink / raw)
To: Adrian Hunter
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kernel, Andi Kleen
In-Reply-To: <344fddd4-718b-ecf3-75f0-585eda90df6f@intel.com>
Em Wed, Nov 09, 2016 at 04:01:12PM +0200, Adrian Hunter escreveu:
> On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
> >>> From: Andi Kleen <ak@linux.intel.com>
> >>>
> >>> Since the unprivileged sched switch event was added in perf,
> >>> PT doesn't need need perf_event_paranoid=-1 anymore for
> >>> per cpu decoding. So remove the obsolete paragraph in
> >>> the documentation.
> >>
> >> Thanks for pointing that out, I'll do something slightly different tho,
> >> pointing out that from kernel X.Y.Z, when the unprivileged
> >> PERF_RECORD_SWITCH metadata event was introduced, this is no longer an
> >> issue, having to be considered only on older kernels.
> >
> > It ended up as:
> >
> > diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
> > index c6c8318e38a2..4d12db118476 100644
> > --- a/tools/perf/Documentation/intel-pt.txt
> > +++ b/tools/perf/Documentation/intel-pt.txt
> > @@ -546,6 +546,18 @@ mode by using the --per-thread option.
> > Privileged vs non-privileged users
> > ----------------------------------
> >
> > +The v4.2 kernel introduced support for a context switch metadata event,
> > +PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
> > +are scheduled out and in, just not by whom, which is left for the
> > +PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
> > +which in turn requires CAP_SYS_ADMIN.
> > +
> > +Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
> > +switches") commit, that introduces these metadata events for further info.
> > +
> > +When working with kernels < v4.2, the following considerations must be taken,
> > +as the sched:sched_switch tracepoints will be used to receive such information:
> > +
> > Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
> > have memory limits imposed upon them. That affects what buffer sizes they can
> > have as outlined above.
>
> Maybe put that last paragraph about memory limits above the new text.
Ok, as it is not affected by the new text, thanks.
- Arnaldo
^ permalink raw reply
* Re: How to package the smixer modules?
From: Tanu Kaskinen @ 2016-11-09 14:39 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hlgwu9gtx.wl-tiwai@suse.de>
On Tue, 2016-11-08 at 15:39 +0100, Takashi Iwai wrote:
> The simple mixer is another layer in ALSA mixer API, and actually it's
> mandatory. So, at least, sbase plugin should be provided always when
> alsa-lib mixer API is used. Other plugins are basically never used
> practically.
>
> It doesn't matter whether to package them separately or not. The only
> point is that sbase plugin should be available when alsa-lib mixer API
> is used.
Thanks for the explanation! If the sbase plugin is essentially a
mandatory accompaniment of libasound, I'll move it to the libasound
package, and since I don't see much benefit in keeping the hda and ac97
plugins in a separate package either, I'll move those too and get rid
of the whole smixer plugin package.
Out of curiosity, in what situation are the hda and ac97 plugins used?
You said that they are practically never used, but surely they have
some purpose?
--
Tanu
https://www.patreon.com/tanuk
^ permalink raw reply
* [PATCH] drm: Make DRM_DEBUG_MM depend on STACKTRACE_SUPPORT
From: Chris Wilson @ 2016-11-09 14:39 UTC (permalink / raw)
To: dri-devel; +Cc: Daniel Vetter
0day continues to complain about trying to save a stacktrace for the
users of the drm_mm range allocator. This time, it is that m68k has no
save_stack_trace(), which is apparently guarded by STACKTRACE_SUPPORT.
Make it depend so!
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dd3d9ae97fe4..9f10c148a4b0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -37,6 +37,7 @@ config DRM_DEBUG_MM
bool "Insert extra checks and debug info into the DRM range managers"
default n
depends on DRM=y
+ depends on STACKTRACE_SUPPORT
select STACKDEPOT
help
Enable allocation tracking of memory manager and leak detection on
--
2.10.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [Qemu-devel] [PULL 3/3] Fix cursesw detection
From: Gerd Hoffmann @ 2016-11-09 14:38 UTC (permalink / raw)
To: qemu-devel; +Cc: Samuel Thibault, Gerd Hoffmann
In-Reply-To: <1478702323-15635-1-git-send-email-kraxel@redhat.com>
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.
To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.
We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Message-id: 20161109102752.13255-1-samuel.thibault@ens-lyon.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
configure | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
else
- curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+ curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
curses_lib_list="$($pkg_config --libs ncursesw 2>/dev/null):-lncursesw:-lcursesw"
fi
curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
resize_term(0, 0);
addwstr(L"wide chars\n");
addnwstr(&wch, 1);
+ add_wch(WACS_DEGREE);
return s != 0;
}
EOF
IFS=:
for curses_inc in $curses_inc_list; do
+ IFS=:
for curses_lib in $curses_lib_list; do
unset IFS
if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
break
fi
done
+ if test "$curses_found" = yes ; then
+ break
+ fi
done
unset IFS
if test "$curses_found" = "yes" ; then
--
1.8.3.1
^ permalink raw reply related
* [Qemu-devel] [PULL for-2.8 0/3] ui: bugfixes for gtk, curses and hid emulation.
From: Gerd Hoffmann @ 2016-11-09 14:38 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann
Hi,
Here is the UI patch queue with three bugfixes,
most importantly the cursesw configure fix.
please pull,
Gerd
The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:
Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +0000)
are available in the git repository at:
git://git.kraxel.org/qemu tags/pull-ui-20161109-1
for you to fetch changes up to ba60f2d18e976ef99238ebce019e26719f2b597c:
Fix cursesw detection (2016-11-09 14:35:47 +0100)
----------------------------------------------------------------
ui: bugfixes for gtk, curses and hid emulation.
----------------------------------------------------------------
Peter Korsgaard (1):
hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc
Samuel Thibault (1):
Fix cursesw detection
Thomas Huth (1):
ui/gtk: Fix build with older versions of gtk
configure | 7 ++++++-
hw/input/hid.c | 4 ++--
ui/gtk.c | 3 ++-
3 files changed, 10 insertions(+), 4 deletions(-)
^ permalink raw reply
* [Qemu-devel] [PULL 1/3] ui/gtk: Fix build with older versions of gtk
From: Gerd Hoffmann @ 2016-11-09 14:38 UTC (permalink / raw)
To: qemu-devel; +Cc: Thomas Huth, Gerd Hoffmann
In-Reply-To: <1478702323-15635-1-git-send-email-kraxel@redhat.com>
From: Thomas Huth <thuth@redhat.com>
GDK_KEY_Delete is only defined with gtk version 2.22 and newer,
on older versions this key was called GDK_Delete instead.
Since this is the case for all GDK_KEY_* defines, change the
already existing preprocessor check there to test for version 2.22,
so we know that we can remove this code block in case we require
that version as a minimum one day.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1478081328-25515-1-git-send-email-thuth@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
ui/gtk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index ca737c4..e816428 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -94,7 +94,7 @@
#define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
#endif
-#ifndef GDK_KEY_0
+#if !GTK_CHECK_VERSION(2, 22, 0)
#define GDK_KEY_0 GDK_0
#define GDK_KEY_1 GDK_1
#define GDK_KEY_2 GDK_2
@@ -104,6 +104,7 @@
#define GDK_KEY_plus GDK_plus
#define GDK_KEY_minus GDK_minus
#define GDK_KEY_Pause GDK_Pause
+#define GDK_KEY_Delete GDK_Delete
#endif
/* Some older mingw versions lack this constant or have
--
1.8.3.1
^ permalink raw reply related
* [Qemu-devel] [PULL 2/3] hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc
From: Gerd Hoffmann @ 2016-11-09 14:38 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Korsgaard, Gerd Hoffmann
In-Reply-To: <1478702323-15635-1-git-send-email-kraxel@redhat.com>
From: Peter Korsgaard <peter@korsgaard.com>
The printscreen/sysrq and pause/break keys currently don't work for guests
using -usbdevice keyboard when accessed through vnc with a gtk-vnc based
client.
The reason for this is a mismatch between gtk-vnc and qemu in how these keys
should be mapped to XT keycodes.
On the original IBM XT these keys behaved differently than other keys.
Quoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html:
The keys PrtSc/SysRq and Pause/Break are special. The former produces
scancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37
together with Shift or Ctrl, but 54 together with (left or right) Alt. (And
one gets the expected sequences upon release. But see below.) The latter
produces scancode sequence e1 1d 45 e1 9d c5 when pressed (without modifier)
and nothing at all upon release. However, together with (left or right)
Ctrl, one gets e0 46 e0 c6, and again nothing at release. It does not
repeat.
Gtk-vnc supports the 'QEMU Extended Key Event Message' RFB extension to send
raw XT keycodes directly to qemu, but the specification doesn't explicitly
specify how to map such long/complicated keycode sequences. From the spec
(https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message)
The keycode is the XT keycode that produced the keysym. An XT keycode is an
XT make scancode sequence encoded to fit in a single U32 quantity. Single
byte XT scancodes with a byte value less than 0x7f are encoded as is.
2-byte XT scancodes whose first byte is 0xe0 and second byte is less than
0x7f are encoded with the high bit of the first byte set
hid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 37
-> 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54).
Likewise, hid.c expects the code without modifiers (e1 1d 45 -> 0xc5 in
RFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46
-> 0xc6 in RFB).
See keymaps.cvs in gtk-vnc for the mapping used:
https://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150
Now, it isn't obvious to me which sequence is really "right", but as the
0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like
the pragmatic solution to me. The USB HID keyboard boot protocol used by
hid.c doesn't have any other mapping applicable to these keys.
The other guest keyboard interfaces (ps/2, virtio, ..) are not affected,
because they handle these keys differently.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Message-id: 20161028145132.1702-1-peter@korsgaard.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
hw/input/hid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/input/hid.c b/hw/input/hid.c
index 5e2850e..fa9cc4c 100644
--- a/hw/input/hid.c
+++ b/hw/input/hid.c
@@ -46,7 +46,7 @@ static const uint8_t hid_usage_keys[0x100] = {
0xe2, 0x2c, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e,
0x3f, 0x40, 0x41, 0x42, 0x43, 0x53, 0x47, 0x5f,
0x60, 0x61, 0x56, 0x5c, 0x5d, 0x5e, 0x57, 0x59,
- 0x5a, 0x5b, 0x62, 0x63, 0x00, 0x00, 0x64, 0x44,
+ 0x5a, 0x5b, 0x62, 0x63, 0x46, 0x00, 0x64, 0x44,
0x45, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e,
0xe8, 0xe9, 0x71, 0x72, 0x73, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x85, 0x00, 0x00, 0x00, 0x00,
@@ -61,7 +61,7 @@ static const uint8_t hid_usage_keys[0x100] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x54, 0x00, 0x46,
0xe6, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00, 0x4a,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x48, 0x4a,
0x52, 0x4b, 0x00, 0x50, 0x00, 0x4f, 0x00, 0x4d,
0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00,
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC 0/4] ALSA controls management using index/device/sub-devices fields
From: Arnaud Pouliquen @ 2016-11-09 14:38 UTC (permalink / raw)
To: Takashi Sakamoto, alsa-devel@alsa-project.org, Charles Keepax,
Vinod Koul
Cc: Takashi Iwai, broonie@kernel.org, lgirdwood@gmail.com
In-Reply-To: <c28a3623-3cf1-5fc1-1ba8-e6785fb967ca@sakamocchi.jp>
Hi,
On 11/09/2016 01:33 PM, Takashi Sakamoto wrote:
> Hi,
>
> On Nov 8 2016 17:11, Arnaud Pouliquen wrote:
>> 3) Patches proposed:
>> Based on these observations, here are some patches that i tested in my
>> environment. There are complementary, and could answer to some
>> limitations mentioned above.
>>
>> 3-1) Alsa-utils patch
>>
>> - iecset: allow to select control with device and sub-device numbers
>> This patch allows to access to 2 iec controls differentiated by
>> device/sub-devices numbers
>> => For me, this patch is mandatory to be able to address the ASoC IEC
>> controls, in case of no fix is implemented to allows index field
>> update in ASoC.
>>
>> 3-2) Alsa driver patches
>> - ASoC: core: allow PCM control binding to PCM device
>> Add relationship between DAIs PCM controls and PCM device.
>>
>> - ALSA: control: increment index field for duplicated control.
>> Generic implementation of the patch proposed in HDA driver
>> (http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b43add)
>>
>> - ASoC: sti: use bind_pcm_ctl
>> implementation of bind_pcm_ctl for sti driver.
>
> In my view, this patchset includes two attempts:
> 1.to add a framework into ALSA SoC part to relate some control element
> sets to PCM devices
> 2.to allow drivers in ALSA SoC part to add some control element sets
> from the same codes according to entries of dtb
>
> To achieve above 2nd attempt, it changes ALSA control core to accept
> several control element sets with the same name by assigning proper
> indexes to the sets.
>
> Well, since your former messages, you continue using the word, 'general'
> or 'generic'. If it were somewhat general, it should satisfy
> requirements in whole this subsystem. Actually, there's none of such
> requirements outside of ALSA SoC part. For the drivers outside of ALSA
> SoC part, design of target sound card is fixed in advance, therefore
> programmers can assign control element sets to PCM devices in usual
> ways. At least, current infrastructure in ALSA control core can satisfy
> the programmers.
>
> Therefore, I think that your attempts includes over-generalization. In
> theory, it can bring over-specification easily and it causes code
> complication or unmaintained codes.
I based my RFC on the fact that i was facing same kind of problem than
HDA driver (last time i mention it). In this context, i don't think that
it was senseless to have a global approach.
If not the good approach, let's refocus on ASoC, that's fine by me.
>
>
> Focusing on ALSA SoC part, there's a requirement to register control
> element sets from the same code, in fact. So I wonder why you don't
> start your explanation in an aspect of it. In short, I can't understand
> the reason that you adhere to such an inappropriate generalization for
> this subsystem.
>
> In this patchset, you adhere to usage of 'index' field. But there's
> another way; assigning different identification information to the
> control element sets. Let us to start discussion from this point? At
> least, Iwai-san said, former driver for Intel High Definition Audio is
> necessarily not a good example for a model to c
> onsider about this issue and the usage of 'index' is not
> well-generalized[1].
>
> Finally, it's better to clear main points of your issue, for practical
> and meaningful discussion for better approaches, before starting this
> discussion, I think. At least, there's over-generalization,
> misunderstandings of design and interfaces, driver-specific historical
> reasons and so on.
>
>
> [1] [alsa-devel] [RFC 0/4] ALSA controls management using
> index/device/sub-devices fields
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/114430.html
>
So I propose to continue discussion on a simple and concrete use case:
The 'IEC958 Playback Default' control.
In my ASoC driver i have one HDMI and one SPDIF outputs.
so I have 2'IEC958 Playback Default' PCM controls.
=> Each control can be set independently.
Regarding control identification field (struct snd_ctl_elem_i):
.numid; => set by ALSA framework
.iface; => must be SNDRV_CTL_ELEM_IFACE_PCM
.device; => must be linked to PCM device , but not possible for
ASoC DAI...
.subdevice => not used in ASoC implementation
.name => 'IEC958 Playback Default'
.index => not used in ASoC, forced to 0 by snd_soc_cnew
Other solution: use control "prefix"? not possible as control has a
pre-defined name.
=> Only solution to differentiate the control: "device" field.
(that seems coherent as it a PCM device).
Issues:
- use "device" in ASOC DAI driver means that driver needs to
define a "virtual" PCM device value, not the PCM device.
=> this break the rule that mention that PCM control should be
linked to a PCM device.
Furthermore, this "virtual" value has to be aligned with the one
defined in alsa-lib conf file(s).
- iecset uses only index to differentiate IEC controls. But in
ASoC implementation this is not possible as index is forced to 0.
Regards
Arnaud
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Jan Glauber @ 2016-11-09 14:38 UTC (permalink / raw)
To: Paul Burton
Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang,
Steven J. Hill
In-Reply-To: <1595446.2T31j1Ekg5@np-p-burton>
On Wed, Nov 09, 2016 at 02:07:58PM +0000, Paul Burton wrote:
> On Wednesday, 9 November 2016 14:41:03 GMT Jan Glauber wrote:
> > Hi Paul,
> >
> > I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
> > register access retries". With debugging enabled I'm getting:
> >
> > <snip>
> >
> > This is not caused by the usleep inside the wait_event but by
> > readq_poll_timeout(). Could you try if it works for you if you only revert
> > this patch?
> >
> > Thanks,
> > Jan
>
> Hi Jan,
>
> If I drop both my patches & just revert 70121f7f3725 ("i2c: octeon: thunderx:
> Limit register access retries") sadly it doesn't fix my system. A boot of a
> cavium_octeon_defconfig kernel with initcall_debug ends with:
>
> calling octeon_mgmt_mod_init+0x0/0x28 @ 1
> initcall octeon_mgmt_mod_init+0x0/0x28 returned 0 after 67 usecs
> calling ds1307_driver_init+0x0/0x10 @ 1
> initcall ds1307_driver_init+0x0/0x10 returned 0 after 19 usecs
> calling octeon_i2c_driver_init+0x0/0x10 @ 1
> ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata1.00: ATA-9: SanDisk SDSSDA240G, Z22000RL, max UDMA/133
> ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sda: sda1 sda2 sda3 sda4
> sd 0:0:0:0: [sda] Attached SCSI disk
> ata2: SATA link down (SStatus 0 SControl 300)
> random: crng init done
>
> As you can see octeon_i2c_driver_init never returns. Are you able to test on
> one of your MIPS-based systems?
CC'ing Steven who might be able to test on MIPS.
> Thanks,
> Paul
^ permalink raw reply
* Re: [PATCH 09/12] exynos-gsc: Simplify system PM even more
From: Ulf Hansson @ 2016-11-09 14:38 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-media, linux-samsung-soc, Sylwester Nawrocki,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Javier Martinez Canillas
In-Reply-To: <1478701441-29107-10-git-send-email-m.szyprowski@samsung.com>
On 9 November 2016 at 15:23, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> System pm callbacks only ensures that device is runtime suspended/resumed,
> so remove them and use generic pm_runtime_force_suspend/resume helper.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> drivers/media/platform/exynos-gsc/gsc-core.c | 21 ++-------------------
> 1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 4859727..1e8b216 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1166,26 +1166,9 @@ static int gsc_runtime_suspend(struct device *dev)
> }
> #endif
>
> -#ifdef CONFIG_PM_SLEEP
> -static int gsc_resume(struct device *dev)
> -{
> - if (!pm_runtime_suspended(dev))
> - return gsc_runtime_resume(dev);
> -
> - return 0;
> -}
> -
> -static int gsc_suspend(struct device *dev)
> -{
> - if (!pm_runtime_suspended(dev))
> - return gsc_runtime_suspend(dev);
> -
> - return 0;
> -}
> -#endif
> -
> static const struct dev_pm_ops gsc_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> + pm_runtime_force_resume)
> SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
> };
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Jan Glauber @ 2016-11-09 14:38 UTC (permalink / raw)
To: Paul Burton
Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang,
Steven J. Hill
In-Reply-To: <1595446.2T31j1Ekg5@np-p-burton>
On Wed, Nov 09, 2016 at 02:07:58PM +0000, Paul Burton wrote:
> On Wednesday, 9 November 2016 14:41:03 GMT Jan Glauber wrote:
> > Hi Paul,
> >
> > I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
> > register access retries". With debugging enabled I'm getting:
> >
> > <snip>
> >
> > This is not caused by the usleep inside the wait_event but by
> > readq_poll_timeout(). Could you try if it works for you if you only revert
> > this patch?
> >
> > Thanks,
> > Jan
>
> Hi Jan,
>
> If I drop both my patches & just revert 70121f7f3725 ("i2c: octeon: thunderx:
> Limit register access retries") sadly it doesn't fix my system. A boot of a
> cavium_octeon_defconfig kernel with initcall_debug ends with:
>
> calling octeon_mgmt_mod_init+0x0/0x28 @ 1
> initcall octeon_mgmt_mod_init+0x0/0x28 returned 0 after 67 usecs
> calling ds1307_driver_init+0x0/0x10 @ 1
> initcall ds1307_driver_init+0x0/0x10 returned 0 after 19 usecs
> calling octeon_i2c_driver_init+0x0/0x10 @ 1
> ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata1.00: ATA-9: SanDisk SDSSDA240G, Z22000RL, max UDMA/133
> ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sda: sda1 sda2 sda3 sda4
> sd 0:0:0:0: [sda] Attached SCSI disk
> ata2: SATA link down (SStatus 0 SControl 300)
> random: crng init done
>
> As you can see octeon_i2c_driver_init never returns. Are you able to test on
> one of your MIPS-based systems?
CC'ing Steven who might be able to test on MIPS.
> Thanks,
> Paul
^ permalink raw reply
* Re: [PATCH] sound: soc-core: make kernel complaints on -EPROBE_DEFER dev_dbg
From: Mark Brown @ 2016-11-09 14:36 UTC (permalink / raw)
To: Ladislav Michl; +Cc: alsa-devel, Liam Girdwood
In-Reply-To: <20161109140036.GB20859@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 562 bytes --]
On Wed, Nov 09, 2016 at 03:00:36PM +0100, Ladislav Michl wrote:
> There is no point having these complaints to be dev_err as
> they are just adding noise to bootlog.
No, errors are errors and not displaying them just makes it harder for
people to debug things. If you don't want to see errors just change
your system configuratiion to hide them. If you don't like deferred
probing please contribute to the efforts to order probing.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-13-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:34 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-freqeuncy" property.
> It should be same behavior, So Use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
applied to my dts64 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:37 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, krzk,
shawn.lin
In-Reply-To: <20161103062135.10697-13-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:34 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-freqeuncy" property.
> It should be same behavior, So Use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
applied to my dts64 branch for 4.10
Thanks
Heiko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.