Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring
>>> Alexey G 05/31/18 7:15 AM >>>
>On Wed, 30 May 2018 02:12:37 -0600 "Jan Beulich" wrote:
> On 29.05.18 at 20:47, wrote:
>>> On Wed, 30 May 2018 03:56:07 +1000
>>> Alexey G wrote:
On Tue, 29 May 2018 08:23:51 -0600
"Jan Beulich" wrote:
On 12.03.18 at 19:33, wrote:
>> @@ -172,10 +173,14 @@ void pci_setup(void)
>>
>> /* Create a list of device BARs in descending order of size. */
>> struct bars {
>> -uint32_t is_64bar;
>> uint32_t devfn;
>> uint32_t bar_reg;
>> uint64_t bar_sz;
>> +uint64_t addr_mask; /* which bits of the base address can be
>> written */
>> +uint32_t bar_data; /* initial value - BAR flags here */
>
>Why 32 bits? You only use the low few ones afaics. Also please avoid fixed
>width
>types unless you really need them.
bar_data is supposed to hold only BAR's kludge bits like 'enabled' bit
values or MMCONFIG width bits. All of them occupy the low dword only
while BAR's high dword is just a part of the address which will be
replaced by allocated one (for mem64 BARs), thus no need to keep the
high half.
So this is a sort of minor optimization -- avoiding using 64-bit operand
size when 32 bit is enough.
>>>
>>> Sorry, looks like I've misread the question. You were actually
>>> suggesting to make bar_data shorter. 8 bits is enough at the moment, so
>>> bar_data can be changed to uint8_t, yes.
>>
>>Right.
>
>Ok, I'll switch to smaller types though not sure if it will make any
>significant impact I'm afraid.
>
>In particular, bar_data will be typically used in 32/64-bit
>arithmetics, using a 32-bit datatype means we avoiding explicit zero
>extension for both 32 and 64-bit operations while for an uint8_t field
>the compiler will have to provide extra MOVZX instructions to embed a
>8-bit operand into 32/64-bit expressions. 32-bit bar_reg can be made
>16-bit in the same way but any memory usage improvements will be
>similarly counteracted by a requirement to use 66h-prefixed
>instructions for it.
Hmm, yes, the space saving from using less wide types are probably indeed
not worth it. But then please switch to "unsigned int" instead of uint_t
whenever the exact size doesn't matter.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 11:25 PM, Boris Ostrovsky wrote:
On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
Oleksandr Andrushchenko (8):
xen/grant-table: Make set/clear page private code shared
xen/balloon: Move common memory reservation routines to a module
xen/grant-table: Allow allocating buffers suitable for DMA
xen/gntdev: Allow mappings for DMA buffers
xen/gntdev: Add initial support for dma-buf UAPI
xen/gntdev: Implement dma-buf export functionality
xen/gntdev: Implement dma-buf import functionality
xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
drivers/xen/Kconfig | 23 +
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 +--
drivers/xen/gntdev.c | 1025
-
I think this calls for gntdev_dma.c.
I assume you mean as a separate file (part of gntdev driver)?
I only had a quick look over gntdev changes but they very much are
concentrated in dma-specific routines.
I tried to do that, but there are some dependencies between the
gntdev.c and gntdev_dma.c,
so finally I decided to put it all together.
You essentially only share file_operations entry points with
original gntdev code, right?
fops + mappings done by gntdev (struct grant_map) and I need to
release map on dma_buf .release
callback which makes some cross-dependencies between modules which
seemed to be not cute
(gntdev keeps its all structs and functions inside, so I cannot
easily access those w/o
helpers).
But I'll try one more time and move all DMA specific stuff into
gntdev_dma.c
Could you please take a quick look at the way I re-structured the
sources here [1]?
If this is what you meant.
I looked at final gntdev.c code and I think at least one of the chunks
there ("DMA buffer export support. ") can also be moved out. It still
have a bit too many ifdefs but it looks better to my eye than jamming
everything into a single file (and I think more code can be moved out,
but we can talk about it when you post the patches so that we can see
context).
Sure, will send v2 after I re-check all the patches
and run some smoke tests again
BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
gntdev_remove_map() is defined under this option and is referenced later
without it.
Will check, thank you
-boris
Thank you,
Oleksandr
-boris
Thank you,
Oleksandr
drivers/xen/grant-table.c | 176 +-
drivers/xen/mem-reservation.c | 134 +
include/uapi/xen/gntdev.h | 106
include/xen/grant_dev.h | 37 ++
include/xen/grant_table.h | 28 +
include/xen/mem_reservation.h | 29 +
10 files changed, 1527 insertions(+), 103 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/grant_dev.h
create mode 100644 include/xen/mem_reservation.h
[1]
https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
On 05/31/2018 09:27 PM, Sameer Goel wrote:
On 5/30/2018 10:13 PM, Manish Jaggi wrote:
On 05/31/2018 04:31 AM, Sameer Goel wrote:
+
+static int arm_smmu_iommu_domain_init(struct domain *d)
Where is iommu_domain initialized?
The function does not use a iommu_domain * variable
Please check iommu.c 2 levels up.
In this function do you see iommu_domain getting allocated or initialized?
As per the name of function arm_smmu iommu_domain_init.
Where is init of iommu_domain in this function?
Well without the xen_domain the iommu_domain is not initialized. It is just the
default value. This generic iommu code makes an .init call to our code for
whatever initialization is needed. So the name here seemed absolutely fine to
me.
Initialization does not always refer to allocation. In this case this is driver
specific initialization. Since, the iommu code is making an init call to the
smmu code hence the name arm_smmu_iommu_domain_init. So, again I agree with
your comments on the domain variable names and I'm making these changes as they
would make the code cleaner. This function name change probably will not do
much but the move along the discussion, let me know what you were thinking.
Sameer, few points
a. all the functions are prefixed with arm_smmu_ , so what the function
is doing can be understood by the rest part of the name
In this case it is iommu_domain_init.
b. By the name it seems to suggest that you are doing some kind of init
for iommu_domain
c. But in this complete function, iommu_domain pointer is never used.
If I take your point, the appropriate name of the function should be
arm_smmu_xen_domain_init().
-Manish
+static int arm_smmu_iommu_domain_init(struct domain *d)
+{
+ struct arm_smmu_xen_domain *xen_domain;
+
+ xen_domain = xzalloc(struct arm_smmu_xen_domain);
+ if (!xen_domain)
+ return -ENOMEM;
+
+ spin_lock_init(_domain->lock);
+ INIT_LIST_HEAD(_domain->contexts);
+
+ dom_iommu(d)->arch.priv = xen_domain;
+
+ return 0;
+}
+
Thanks,
Sameer
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.6-testing test] 123408: regressions - FAIL
flight 123408 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123408/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 122997 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 122997 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 122997 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 122997 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 122997 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 122997 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 122997 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 122997 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122923 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122997 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122997 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122997 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 122997 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122997 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 122997 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122997 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 122997 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122997 test-xtf-amd64-amd64-5 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-5 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-3 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-3 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 37 xtf/test-hvm32pae-memop-seg fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-2 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-1 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-memop-seg fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-1 77 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never
Re: [Xen-devel] [PATCH for-4.11] x86/VT-x: Fix printing of EFER in vmcs_dump_vcpu()
On 31/05/18 18:03, Andrew Cooper wrote: > This is essentially a "take 2" of c/s 82540b66ce "x86/VT-x: Fix determination > of EFER.LMA in vmcs_dump_vcpu()" because in hindight, that change was more > problematic than useful. > > The original reason was to fix the logic for determining when not to print the > PDPTE pointers. However, mutating the efer variable (particularly LME and > LMA) before printing it interferes with diagnosing vmentry failures. > > Instead of modifying efer, change the PDPTE conditional to use > VM_ENTRY_IA32E_MODE. > > Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 08/10] arm: add QEMU, Rcar3 and MPSoC configs
Hi Stefano, Sorry for formatting. On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote: > Add a "Platform Support" menu with three umbrella kconfig options: QEMU, > RCAR3 and MPSOC. They enable the required options for their hardware > platform. > This patch is nothing close to what we discussed. As far as I can tell, the tiny.config will end up to select all the platforms with their driver. It will not be possible to deselect the driver selected for a platform afterwards. I still think the best if providing a choice list where only one option can be selected. I would like to understand why you didn't go this path. Cheers, > In the case of the MPSOC that has a platform file under > arch/arm/platforms/, build the file if MPSOC. > > Signed-off-by: Stefano Stabellini > CC: artem_myga...@epam.com > CC: volodymyr_babc...@epam.com > > --- > Changes in v4: > - fix GICv3/GICV3 > - default y to all options > - build xilinx-zynqmp if MPSOC > --- > xen/arch/arm/Kconfig| 2 ++ > xen/arch/arm/platforms/Kconfig | 30 ++ > xen/arch/arm/platforms/Makefile | 2 +- > 3 files changed, 33 insertions(+), 1 deletion(-) > create mode 100644 xen/arch/arm/platforms/Kconfig > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 2b87111..75cacfb 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR > config ARM32_HARDEN_BRANCH_PREDICTOR > def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR > > +source "arch/arm/platforms/Kconfig" > + > source "common/Kconfig" > > source "drivers/Kconfig" > diff --git a/xen/arch/arm/platforms/Kconfig > b/xen/arch/arm/platforms/Kconfig > new file mode 100644 > index 000..fea8f9a > --- /dev/null > +++ b/xen/arch/arm/platforms/Kconfig > @@ -0,0 +1,30 @@ > +menu "Platform Support" > + > +config QEMU > + bool "QEMU aarch virt machine support" > + default y > + depends on ARM_64 > + select GICV3 > + select HAS_PL011 > + ---help--- > + Enable all the required drivers for QEMU aarch64 virt emulated > + machine. > + > +config RCAR3 > + bool "Renesas RCar3 support" > + default y > + depends on ARM_64 > + select HAS_SCIF > + ---help--- > + Enable all the required drivers for Renesas RCar3 > + > +config MPSOC > + bool "Xilinx Ultrascale+ MPSoC support" > + default y > + depends on ARM_64 > + select HAS_CADENCE_UART > + select ARM_SMMU > + ---help--- > + Enable all the required drivers for Xilinx Ultrascale+ MPSoC > + > +endmenu > diff --git a/xen/arch/arm/platforms/Makefile > b/xen/arch/arm/platforms/Makefile > index 80e555c..f4ff411 100644 > --- a/xen/arch/arm/platforms/Makefile > +++ b/xen/arch/arm/platforms/Makefile > @@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o > obj-y += sunxi.o > obj-$(CONFIG_ARM_64) += thunderx.o > obj-$(CONFIG_ARM_64) += xgene-storm.o > -obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o > +obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o > -- > 1.9.1 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 07/10] arm: add a tiny kconfig configuration
Hi, Sorry for the formatting. On Thu, 31 May 2018, 22:50 Stefano Stabellini, wrote: > Add a tiny kconfig configuration. Enabled NULL and Credit schedulers. > Support only 8 cpus. It only carries non-default options (use make > olddefconfig to produce a complete .config file). > > Signed-off-by: Stefano Stabellini > > --- > Note that this approach has a limitation: it is not possible to "select > a range". In other words, using tiny.config NR_CPUS is set to 4. It is > not possible to increase it to 8 from config RCAR3. > Is that still true? I thought we discussed a solution to do it yesterday. By that, I mean the platform would be selected at olddefconfig. Cheers, --- > xen/arch/arm/configs/tiny.conf | 43 > ++ > 1 file changed, 43 insertions(+) > create mode 100644 xen/arch/arm/configs/tiny.conf > > diff --git a/xen/arch/arm/configs/tiny.conf > b/xen/arch/arm/configs/tiny.conf > new file mode 100644 > index 000..e9a5e65 > --- /dev/null > +++ b/xen/arch/arm/configs/tiny.conf > @@ -0,0 +1,43 @@ > +CONFIG_ARM_64=y > +CONFIG_ARM=y > + > +# > +# Architecture Features > +# > +# CONFIG_GICV3 is not set > +# CONFIG_MEM_ACCESS is not set > +# CONFIG_SBSA_VUART_CONSOLE is not set > + > +# > +# Common Features > +# > +# CONFIG_TMEM is not set > + > +# > +# Schedulers > +# > +# CONFIG_SCHED_CREDIT2 is not set > +# CONFIG_SCHED_RTDS is not set > +# CONFIG_SCHED_ARINC653 is not set > +CONFIG_SCHED_NULL=y > +CONFIG_SCHED_NULL_DEFAULT=y > +CONFIG_SCHED_DEFAULT="null" > +# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set > + > +# > +# Device Drivers > +# > +# CONFIG_HAS_NS16550 is not set > +# CONFIG_HAS_CADENCE_UART is not set > +# CONFIG_HAS_MVEBU is not set > +# CONFIG_HAS_PL011 is not set > +# CONFIG_HAS_SCIF is not set > +# CONFIG_ARM_SMMU is not set > + > +# > +# Debugging Options > +# > +# CONFIG_DEBUG is not set > +# CONFIG_FRAME_POINTER is not set > +# CONFIG_VERBOSE_DEBUG is not set > +# CONFIG_SCRUB_DEBUG is not set > -- > 1.9.1 > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-wheezy test] 74767: all pass
flight 74767 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74767/ Perfect :-) All tests in this flight passed as required baseline version: flight 74740 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub pass test-amd64-i386-amd64-wheezy-netboot-pygrub pass test-amd64-amd64-i386-wheezy-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.7-testing test] 123404: regressions - FAIL
flight 123404 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123404/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 123144 test-xtf-amd64-amd64-37 xen-boot fail REGR. vs. 123144 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl7 xen-boot fail REGR. vs. 123144 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 123144 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 123144 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-xtf-amd64-amd64-57 xen-boot fail REGR. vs. 123144 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 123144 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 123144 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 123144 test-xtf-amd64-amd64-27 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 123144 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 123144 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 123144 test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123144 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 123144 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-migrupgrade 11 xen-boot/dst_hostfail REGR. vs. 123144 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123144 test-amd64-amd64-migrupgrade 11 xen-boot/dst_hostfail REGR. vs. 123144 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 123144 test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 123144 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 123144 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 123144 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 123144 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 123144
[Xen-devel] [linux-next test] 123403: regressions - FAIL
flight 123403 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/123403/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-examine 8 reboot fail REGR. vs. 123310 test-armhf-armhf-xl-xsm 7 xen-boot fail REGR. vs. 123310 test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 123310 test-armhf-armhf-xl-multivcpu 7 xen-bootfail REGR. vs. 123310 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 123310 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 123310 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 123310 test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 123310 test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 123310 test-armhf-armhf-xl-cubietruck 7 xen-boot fail REGR. vs. 123310 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 123310 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123310 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123310 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123310 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123310 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123310 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123310 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 123310 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: linux5dfe68023df2160b99be79ed830555102236a20c baseline version: linux786b71f5b754273ccef6d9462e52062b3e1f9877 Last test of basis (not found) Failing since (not found) Testing same since 123403 2018-05-30 09:19:11 Z1 days1 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt
[Xen-devel] [PATCH v4 06/10] arm: make it possible to disable the SMMU driver
Introduce a Kconfig option for the ARM SMMUv1 and SMMUv2 driver. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall Acked-by: Jan Beulich CC: jbeul...@suse.com --- Changes in v3: - rename SMMUv2 to ARM_SMMU - improve help message - use if ARM Changes in v2: - rename HAS_SMMUv2 to SMMUv2 - move SMMUv2 to xen/drivers/passthrough/Kconfig --- xen/drivers/passthrough/Kconfig | 12 xen/drivers/passthrough/arm/Makefile | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/Kconfig b/xen/drivers/passthrough/Kconfig index 8d90b67..a3c0649 100644 --- a/xen/drivers/passthrough/Kconfig +++ b/xen/drivers/passthrough/Kconfig @@ -1,3 +1,15 @@ config HAS_PASSTHROUGH bool + +if ARM +config ARM_SMMU + bool "ARM SMMUv1 and v2 driver" + default y + ---help--- + Support for implementations of the ARM System MMU architecture + versions 1 and 2. + + Say Y here if your SoC includes an IOMMU device implementing the + ARM SMMU architecture. +endif diff --git a/xen/drivers/passthrough/arm/Makefile b/xen/drivers/passthrough/arm/Makefile index f4cd26e..0156431 100644 --- a/xen/drivers/passthrough/arm/Makefile +++ b/xen/drivers/passthrough/arm/Makefile @@ -1,2 +1,2 @@ obj-y += iommu.o -obj-y += smmu.o +obj-$(ARM_SMMU) += smmu.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 05/10] make it possible to enable/disable UART drivers
All the UART drivers are silent options. Add one line descriptions so that can be de/selected via menuconfig. Add an x86 dependency to HAS_EHCI: EHCI PCI has not been used on ARM. In fact, it depends on PCI, and moreover we have drivers for several embedded UARTs for various ARM boards. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- The next patch will take care of fixing arch dependencies. Changes in v4: - improve commit message - remove prompt for HAS_EHCI Changes in v3: - NS16550 prompt if ARM Changes in v2: - make HAS_EHCI depend on x86 --- xen/drivers/char/Kconfig | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index cc78ec3..b1f07f8 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -1,11 +1,11 @@ config HAS_NS16550 - bool + bool "NS16550 UART driver" if ARM default y help This selects the 16550-series UART support. For most systems, say Y. config HAS_CADENCE_UART - bool + bool "Xilinx Cadence UART driver" default y depends on ARM_64 help @@ -13,7 +13,7 @@ config HAS_CADENCE_UART based board, say Y. config HAS_MVEBU - bool + bool "Marvell MVEBU UART driver" default y depends on ARM_64 help @@ -21,7 +21,7 @@ config HAS_MVEBU based board, say Y. config HAS_PL011 - bool + bool "ARM PL011 UART driver" default y depends on ARM help @@ -29,7 +29,7 @@ config HAS_PL011 an Integrator/PP2, Integrator/CP or Versatile platform, say Y. config HAS_EXYNOS4210 - bool + bool "Samsung Exynos 4210 UART driver" default y depends on ARM_32 help @@ -37,7 +37,7 @@ config HAS_EXYNOS4210 Exynos based board, say Y. config HAS_OMAP - bool + bool "Texas Instruments OMAP UART driver" default y depends on ARM_32 help @@ -45,7 +45,7 @@ config HAS_OMAP Instruments based CPU, say Y. config HAS_SCIF - bool + bool "SuperH SCI(F) UART driver" default y depends on ARM help @@ -54,6 +54,7 @@ config HAS_SCIF config HAS_EHCI bool + depends on X86 help This selects the USB based EHCI debug port to be used as a UART. If you have an x86 based system with USB, say Y. -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 08/10] arm: add QEMU, Rcar3 and MPSoC configs
Add a "Platform Support" menu with three umbrella kconfig options: QEMU, RCAR3 and MPSOC. They enable the required options for their hardware platform. In the case of the MPSOC that has a platform file under arch/arm/platforms/, build the file if MPSOC. Signed-off-by: Stefano Stabellini CC: artem_myga...@epam.com CC: volodymyr_babc...@epam.com --- Changes in v4: - fix GICv3/GICV3 - default y to all options - build xilinx-zynqmp if MPSOC --- xen/arch/arm/Kconfig| 2 ++ xen/arch/arm/platforms/Kconfig | 30 ++ xen/arch/arm/platforms/Makefile | 2 +- 3 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/platforms/Kconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2b87111..75cacfb 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR +source "arch/arm/platforms/Kconfig" + source "common/Kconfig" source "drivers/Kconfig" diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig new file mode 100644 index 000..fea8f9a --- /dev/null +++ b/xen/arch/arm/platforms/Kconfig @@ -0,0 +1,30 @@ +menu "Platform Support" + +config QEMU + bool "QEMU aarch virt machine support" + default y + depends on ARM_64 + select GICV3 + select HAS_PL011 + ---help--- + Enable all the required drivers for QEMU aarch64 virt emulated + machine. + +config RCAR3 + bool "Renesas RCar3 support" + default y + depends on ARM_64 + select HAS_SCIF + ---help--- + Enable all the required drivers for Renesas RCar3 + +config MPSOC + bool "Xilinx Ultrascale+ MPSoC support" + default y + depends on ARM_64 + select HAS_CADENCE_UART + select ARM_SMMU + ---help--- + Enable all the required drivers for Xilinx Ultrascale+ MPSoC + +endmenu diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 80e555c..f4ff411 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o obj-y += sunxi.o obj-$(CONFIG_ARM_64) += thunderx.o obj-$(CONFIG_ARM_64) += xgene-storm.o -obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o +obj-$(CONFIG_MPSOC) += xilinx-zynqmp.o -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 02/10] arm: make it possible to disable HAS_GICV3
Today it is a silent option. This patch adds a one line description and makes it optional. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall --- Changes in v3: - remove any changes to MEM_ACCESS - update commit message Changes in v2: - make HAS_GICv3 depend on ARM_64 - remove modifications to ARM_HDLCD kconfig, it has been removed --- xen/arch/arm/Kconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 4dc7ef5..fb69a66 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -12,7 +12,6 @@ config ARM_32 config ARM_64 def_bool y depends on 64BIT - select HAS_GICV3 config ARM def_bool y @@ -42,6 +41,13 @@ config ACPI config HAS_GICV3 bool + prompt "GICv3 driver" + depends on ARM_64 + default y + ---help--- + + Driver for the ARM Generic Interrupt Controller v3. + If unsure, say Y config HAS_ITS bool -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 0/10] arm: more kconfig configurability and small default configs
Hi all, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. First, the series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. Then, it introduces a reference kconfig for Renesas RCar (due to popular demand, candidate for certifications) and for QEMU aarch64 (not for certifications, but useful for debugging). The last patch in the series adds a convenient cloc target to count the total lines of code of the source files built. As a consequence of these changes, some options will become user-visible and not dependent on CONFIG_EXPERT. It does not mean that Xen Project will security support all possible combinations of kconfig options. Instead, there will be a small set of pre-canned configurations that will be supported. See: https://marc.info/?l=xen-devel=152424389512432 One note about Kconfig renaming: I can see the benefit of being consistent with the naming and using HAS_ only for options that are always enabled, but I really don't have a strong opinion on this topic. Cheers, Stefano Stefano Stabellini (10): arm: remove the ARM HDLCD driver arm: make it possible to disable HAS_GICV3 arm: rename HAS_GICV3 to GICV3 Make MEM_ACCESS configurable make it possible to enable/disable UART drivers arm: make it possible to disable the SMMU driver arm: add a tiny kconfig configuration arm: add QEMU, Rcar3 and MPSoC configs xen: add cloc target xen: add per-platform defaults for NR_CPUS tools/firmware/xen-dir/shim.config | 2 +- xen/Makefile | 12 ++ xen/arch/Kconfig | 3 + xen/arch/arm/Kconfig | 17 +- xen/arch/arm/Makefile| 4 +- xen/arch/arm/configs/tiny.conf | 43 + xen/arch/arm/platforms/Kconfig | 30 xen/arch/arm/platforms/Makefile | 2 +- xen/arch/arm/platforms/vexpress.c| 35 xen/arch/arm/vgic.c | 2 +- xen/arch/arm/vgic/vgic.c | 2 +- xen/arch/x86/Kconfig | 2 +- xen/common/Kconfig | 12 +- xen/common/Makefile | 2 +- xen/common/domctl.c | 2 +- xen/drivers/char/Kconfig | 15 +- xen/drivers/passthrough/Kconfig | 12 ++ xen/drivers/passthrough/arm/Makefile | 2 +- xen/drivers/video/Kconfig| 3 - xen/drivers/video/Makefile | 1 - xen/drivers/video/arm_hdlcd.c| 281 --- xen/include/asm-arm/gic.h| 4 +- xen/include/asm-arm/platforms/vexpress.h | 6 - xen/include/asm-arm/vgic.h | 4 +- xen/include/xen/mem_access.h | 4 +- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h| 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 4 +- 29 files changed, 151 insertions(+), 363 deletions(-) create mode 100644 xen/arch/arm/configs/tiny.conf create mode 100644 xen/arch/arm/platforms/Kconfig delete mode 100644 xen/drivers/video/arm_hdlcd.c ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 01/10] arm: remove the ARM HDLCD driver
The ARM HDLCD driver is unused. The device itself can only be found on
Virtual Express boards that are for early development only. Remove the
driver.
Also remove vexpress_syscfg, now unused, and "select VIDEO" that is not
useful anymore.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
Changes in v3:
- remove "select VIDEO"
- remove vexpress_syscfg
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 2 -
xen/arch/arm/platforms/vexpress.c| 35
xen/drivers/video/Kconfig| 3 -
xen/drivers/video/Makefile | 1 -
xen/drivers/video/arm_hdlcd.c| 281 ---
xen/include/asm-arm/platforms/vexpress.h | 6 -
6 files changed, 328 deletions(-)
delete mode 100644 xen/drivers/video/arm_hdlcd.c
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c..4dc7ef5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,12 +17,10 @@ config ARM_64
config ARM
def_bool y
select HAS_ALTERNATIVE
- select HAS_ARM_HDLCD
select HAS_DEVICE_TREE
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
- select VIDEO
config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/platforms/vexpress.c
b/xen/arch/arm/platforms/vexpress.c
index 70839d6..b6193f7 100644
--- a/xen/arch/arm/platforms/vexpress.c
+++ b/xen/arch/arm/platforms/vexpress.c
@@ -59,41 +59,6 @@ static inline int vexpress_ctrl_start(uint32_t *syscfg, int
write,
return 0;
}
-int vexpress_syscfg(int write, int function, int device, uint32_t *data)
-{
-uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
-int ret = -1;
-
-set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE),
- PAGE_HYPERVISOR_NOCACHE);
-
-if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
-goto out;
-
-/* clear the complete bit in the V2M_SYS_CFGSTAT status register */
-syscfg[V2M_SYS_CFGSTAT/4] = 0;
-
-if ( write )
-{
-/* write data */
-syscfg[V2M_SYS_CFGDATA/4] = *data;
-
-if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-goto out;
-} else {
-if ( vexpress_ctrl_start(syscfg, write, function, device) < 0 )
-goto out;
-else
-/* read data */
-*data = syscfg[V2M_SYS_CFGDATA/4];
-}
-
-ret = 0;
-out:
-clear_fixmap(FIXMAP_MISC);
-return ret;
-}
-
/*
* TODO: Get base address from the device tree
* See arm,vexpress-reset node
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 52e8ce6..41ca503 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -11,6 +11,3 @@ config VGA
Enable VGA output for the Xen hypervisor.
If unsure, say Y.
-
-config HAS_ARM_HDLCD
- bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 2bb91d6..2b3fc76 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,4 +4,3 @@ obj-$(CONFIG_VIDEO) += font_8x16.o
obj-$(CONFIG_VIDEO) += font_8x8.o
obj-$(CONFIG_VIDEO) += lfb.o
obj-$(CONFIG_VGA) += vesa.o
-obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
deleted file mode 100644
index e1174b2..000
--- a/xen/drivers/video/arm_hdlcd.c
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * xen/drivers/video/arm_hdlcd.c
- *
- * Driver for ARM HDLCD Controller
- *
- * Stefano Stabellini
- * Copyright (c) 2013 Citrix Systems.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "font.h"
-#include "lfb.h"
-#include "modelines.h"
-
-#define HDLCD ((volatile uint32_t *) FIXMAP_ADDR(FIXMAP_MISC))
-
-#define HDLCD_INTMASK (0x18/4)
-#define HDLCD_FBBASE(0x100/4)
-#define HDLCD_LINELENGTH(0x104/4)
-#define HDLCD_LINECOUNT (0x108/4)
-#define HDLCD_LINEPITCH (0x10C/4)
-#define HDLCD_BUS (0x110/4)
-#define HDLCD_VSYNC (0x200/4)
-#define HDLCD_VBACK (0x204/4)
-#define HDLCD_VDATA (0x208/4)
-#define HDLCD_VFRONT(0x20C/4)
-#define HDLCD_HSYNC (0x210/4)
-#define HDLCD_HBACK (0x214/4)
-#define HDLCD_HDATA (0x218/4)
-#define HDLCD_HFRONT(0x21C/4)
-#define HDLCD_POLARITIES(0x220/4)
-#define HDLCD_COMMAND (0x230/4)
-#define HDLCD_PF(0x240/4)
[Xen-devel] [PATCH v4 04/10] Make MEM_ACCESS configurable
Select MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS is not
configurable on x86. Avoid selecting it on ARM.
Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere. Add a prompt and a
description to MEM_ACCESS in xen/common/Kconfig.
The result is that the user-visible option is MEM_ACCESS, and it is
configurable only on ARM (enabled by default).
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: julien.gr...@arm.com
CC: konrad.w...@oracle.com
CC: sstabell...@kernel.org
CC: t...@xen.org
CC: wei.l...@citrix.com
---
Changes in v4:
- remove HAS_MEM_ACCESS
- move MEM_ACCESS_ALWAYS_ON to common
- combile default and bool to def_bool
Changes in v3:
- keep HAS_MEM_ACCESS to mark that an arch can do MEM_ACCESS
- introduce MEM_ACCESS_ALWAYS_ON
- the main MEM_ACCESS option is in xen/common/Kconfig
Changes in v2:
- patch added
---
tools/firmware/xen-dir/shim.config | 2 +-
xen/arch/arm/Kconfig | 1 -
xen/arch/x86/Kconfig | 2 +-
xen/common/Kconfig | 12 ++--
xen/common/Makefile| 2 +-
xen/common/domctl.c| 2 +-
xen/include/xen/mem_access.h | 4 ++--
xen/include/xsm/dummy.h| 2 +-
xen/include/xsm/xsm.h | 4 ++--
xen/xsm/dummy.c| 2 +-
xen/xsm/flask/hooks.c | 4 ++--
11 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/tools/firmware/xen-dir/shim.config
b/tools/firmware/xen-dir/shim.config
index 4d5630f..21d7075 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -29,7 +29,7 @@ CONFIG_COMPAT=y
CONFIG_CORE_PARKING=y
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_EX_TABLE=y
-CONFIG_HAS_MEM_ACCESS=y
+CONFIG_MEM_ACCESS=y
CONFIG_HAS_MEM_PAGING=y
CONFIG_HAS_MEM_SHARING=y
CONFIG_HAS_PDX=y
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 66adce4..2b87111 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,7 +17,6 @@ config ARM
def_bool y
select HAS_ALTERNATIVE
select HAS_DEVICE_TREE
- select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index f64fc56..9a85fe9 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -15,7 +15,7 @@ config X86
select HAS_GDBSX
select HAS_IOPORTS
select HAS_KEXEC
- select HAS_MEM_ACCESS
+ select MEM_ACCESS_ALWAYS_ON
select HAS_MEM_PAGING
select HAS_MEM_SHARING
select HAS_NS16550
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 9043dce..c7a00f1 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -20,8 +20,16 @@ config HAS_DEVICE_TREE
config HAS_EX_TABLE
bool
-config HAS_MEM_ACCESS
- bool
+config MEM_ACCESS_ALWAYS_ON
+ def_bool n
+
+config MEM_ACCESS
+ def_bool y
+ prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON
+ ---help---
+
+ Framework to configure memory access types for guests and receive
+ related events in userspace.
config HAS_MEM_PAGING
bool
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 24d4752..6f2b3fc 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -22,7 +22,7 @@ obj-y += lib.o
obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o
obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
obj-y += lzo.o
-obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o
+obj-$(CONFIG_MEM_ACCESS) += mem_access.o
obj-y += memory.o
obj-y += monitor.o
obj-y += multicall.o
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9b7bc08..891ad58 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1085,7 +1085,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
copyback = 1;
break;
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
case XEN_DOMCTL_set_access_required:
if ( unlikely(current->domain == d) ) /* no domain_pause() */
ret = -EPERM;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 5ab34c1..7e95eab 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -78,7 +78,7 @@ long p2m_set_mem_access_multi(struct domain *d,
*/
int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access);
-#ifdef CONFIG_HAS_MEM_ACCESS
+#ifdef CONFIG_MEM_ACCESS
int mem_access_memop(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
#else
@@ -88,7 +88,7 @@ int mem_access_memop(unsigned long cmd,
{
return -ENOSYS;
}
-#endif /* CONFIG_HAS_MEM_ACCESS */
+#endif /* CONFIG_MEM_ACCESS */
#endif /* _XEN_MEM_ACCESS_H */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..b0ac1f6 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@
[Xen-devel] [PATCH v4 03/10] arm: rename HAS_GICV3 to GICV3
HAS_GICV3 has become selectable by the user. To mark the change, rename
the option from HAS_GICV3 to GICV3.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no changes
Changes in v2:
- patch added
---
xen/arch/arm/Kconfig | 4 ++--
xen/arch/arm/Makefile | 4 ++--
xen/arch/arm/vgic.c| 2 +-
xen/arch/arm/vgic/vgic.c | 2 +-
xen/include/asm-arm/gic.h | 4 ++--
xen/include/asm-arm/vgic.h | 4 ++--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index fb69a66..66adce4 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -39,7 +39,7 @@ config ACPI
Advanced Configuration and Power Interface (ACPI) support for Xen is
an alternative to device tree on ARM64.
-config HAS_GICV3
+config GICV3
bool
prompt "GICv3 driver"
depends on ARM_64
@@ -52,7 +52,7 @@ config HAS_GICV3
config HAS_ITS
bool
prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
-depends on HAS_GICV3 && !NEW_VGIC
+depends on GICV3 && !NEW_VGIC
config NEW_VGIC
bool
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a9533b1..b9c2fb7 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,7 +17,7 @@ obj-y += domctl.o
obj-$(EARLY_PRINTK) += early_printk.o
obj-y += gic.o
obj-y += gic-v2.o
-obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_GICV3) += gic-v3.o
obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
obj-y += guestcopy.o
@@ -51,7 +51,7 @@ ifneq ($(CONFIG_NEW_VGIC),y)
obj-y += gic-vgic.o
obj-y += vgic.o
obj-y += vgic-v2.o
-obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
+obj-$(CONFIG_GICV3) += vgic-v3.o
obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
endif
obj-y += vm_event.o
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3fafdd0..7a2c455 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -98,7 +98,7 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
{
switch ( d->arch.vgic.version )
{
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
case GIC_V3:
if ( vgic_v3_init(d, mmio_count) )
return -ENODEV;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index a35449b..832632a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -974,7 +974,7 @@ unsigned int vgic_max_vcpus(const struct domain *d)
return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
}
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/* Dummy implementation to allow building without actual vGICv3 support. */
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 58b910f..22fa122 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -166,7 +166,7 @@
#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3")
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/*
* GICv3 registers that needs to be saved/restored
*/
@@ -194,7 +194,7 @@ struct gic_v2 {
*/
union gic_state_data {
struct gic_v2 v2;
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
struct gic_v3 v3;
#endif
};
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a58ea3..374fdaa 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -156,7 +156,7 @@ struct vgic_dist {
struct pending_irq *pending_irqs;
/* Base address for guest GIC */
paddr_t dbase; /* Distributor base address */
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
/* GIC V3 addressing */
/* List of contiguous occupied by the redistributors */
struct vgic_rdist_region {
@@ -359,7 +359,7 @@ unsigned int vgic_max_vcpus(const struct domain *d);
void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
paddr_t vbase, uint32_t aliased_offset);
-#ifdef CONFIG_HAS_GICV3
+#ifdef CONFIG_GICV3
struct rdist_region;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 10/10] xen: add per-platform defaults for NR_CPUS
Add specific per-platform defaults for NR_CPUS. Note that the order of the defaults matter: they need to go first, otherwise the generic defaults will be applied. This is done so that Xen builds customized for a specific hardware platform can have the right NR_CPUS number. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- xen/arch/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index cf0acb7..d451eb8 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -2,6 +2,9 @@ config NR_CPUS int "Maximum number of physical CPUs" range 1 4095 + default "8" if ARM && RCAR3 + default "4" if ARM && QEMU + default "4" if ARM && MPSOC default "256" if X86 default "128" if ARM ---help--- -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 07/10] arm: add a tiny kconfig configuration
Add a tiny kconfig configuration. Enabled NULL and Credit schedulers. Support only 8 cpus. It only carries non-default options (use make olddefconfig to produce a complete .config file). Signed-off-by: Stefano Stabellini --- Note that this approach has a limitation: it is not possible to "select a range". In other words, using tiny.config NR_CPUS is set to 4. It is not possible to increase it to 8 from config RCAR3. --- xen/arch/arm/configs/tiny.conf | 43 ++ 1 file changed, 43 insertions(+) create mode 100644 xen/arch/arm/configs/tiny.conf diff --git a/xen/arch/arm/configs/tiny.conf b/xen/arch/arm/configs/tiny.conf new file mode 100644 index 000..e9a5e65 --- /dev/null +++ b/xen/arch/arm/configs/tiny.conf @@ -0,0 +1,43 @@ +CONFIG_ARM_64=y +CONFIG_ARM=y + +# +# Architecture Features +# +# CONFIG_GICV3 is not set +# CONFIG_MEM_ACCESS is not set +# CONFIG_SBSA_VUART_CONSOLE is not set + +# +# Common Features +# +# CONFIG_TMEM is not set + +# +# Schedulers +# +# CONFIG_SCHED_CREDIT2 is not set +# CONFIG_SCHED_RTDS is not set +# CONFIG_SCHED_ARINC653 is not set +CONFIG_SCHED_NULL=y +CONFIG_SCHED_NULL_DEFAULT=y +CONFIG_SCHED_DEFAULT="null" +# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set + +# +# Device Drivers +# +# CONFIG_HAS_NS16550 is not set +# CONFIG_HAS_CADENCE_UART is not set +# CONFIG_HAS_MVEBU is not set +# CONFIG_HAS_PL011 is not set +# CONFIG_HAS_SCIF is not set +# CONFIG_ARM_SMMU is not set + +# +# Debugging Options +# +# CONFIG_DEBUG is not set +# CONFIG_FRAME_POINTER is not set +# CONFIG_VERBOSE_DEBUG is not set +# CONFIG_SCRUB_DEBUG is not set -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 09/10] xen: add cloc target
Add a Xen build target to count the lines of code of the source files built. Uses `cloc' to do the job. With Xen on ARM taking off in embedded, IoT, and automotive, we are seeing more and more uses of Xen in constrained environments. Users and system integrators want the smallest Xen and Dom0 configurations. Some of these deployments require certifications, where you definitely want the smallest lines of code count. I provided this patch to give us the lines of code count for that purpose. Use the .o.d files to account for all the built source files. Generate a list for the `cloc' utility and invoke `cloc'. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- Changes in v4: - use grep regex to get multiple source files from .d files Changes in v3: - remove build as dependecy for the cloc target Changes in v2: - change implementation to use .o.d to find built source files --- xen/Makefile | 12 1 file changed, 12 insertions(+) diff --git a/xen/Makefile b/xen/Makefile index 62d479c..338d5a3 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -267,3 +267,15 @@ $(KCONFIG_CONFIG): include/config/auto.conf.cmd: ; -include $(BASEDIR)/include/config/auto.conf.cmd + +.PHONY: cloc +cloc: + $(eval tmpfile := $(shell mktemp)) + $(foreach f, $(shell find $(BASEDIR) -name *.o.d), \ + $(eval path := $(dir $(f))) \ + $(eval names := $(shell grep -o "[a-zA-Z0-9_/-]*\.[cS]" $(f))) \ + $(foreach sf, $(names), \ + $(shell if test -f $(path)/$(sf) ; then echo $(path)/$(sf) >> $(tmpfile); fi;))) + cloc --list-file=$(tmpfile) + rm $(tmpfile) + -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 09/10] arm: add QEMU, Rcar3 and MPSoC configs
On Wed, 30 May 2018, Julien Grall wrote:
> On 30/05/2018 22:39, Stefano Stabellini wrote:
> > On Tue, 29 May 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 23/05/18 01:25, Stefano Stabellini wrote:
> > > > Add a "Platform Support" menu with three umbrella kconfig options: QEMU,
> > > > RCAR3 and MPSOC. They enable the required options for their hardware
> > > > platform.
> > > >
> > > > They are introduced for convience: the user will be able to simply open
> > > > the menu and enable the right config for her platform.
> > > >
> > > > Signed-off-by: Stefano Stabellini
> > > > CC: artem_myga...@epam.com
> > > > CC: volodymyr_babc...@epam.com
> > > >
> > > > ---
> > > > Note that this approach has a limitation: it is not possible to "select
> > > > a range". In other words, using tiny.config NR_CPUS is set to 4. It is
> > > > not possible to increase it to 8 from config RCAR3.
> > >
> > > What you can do is:
> > >
> > > config NR_CPUS
> > > range ...
> > > default "8" if (RCAR3)
> > > default "x" if (QEMU)
> > > default 64
> > >
> > > This would imply to move NR_CPUS in arch/{arm,x86}/Kconfig.
> > >
> > > This solution is not very nice, but at least would provide a better
> > > experience
> > > to the user.
> >
> > Unfortunately, make olddefconfig is executed automatically when make is
> > called, adding CONFIG_NR_CPUS=128. Thus, unless tiny.config has already
> > CONFIG_RCAR3 in it, the correct default won't be applied.
> >
> > This suggestions only make sense if we introduce per-platform configs,
> > such as xen/arch/arm/configs/tiny-rcar3.config.
>
> The other solution is to introduce a new command (or script) that will select
> the platform at the same time as olddefconfig.
>
> This would avoid to create a config per board and still keeping only one tiny
> config.
I am not looking forward to making changes to the kconfig commands, but
fortunately I was wrong on my previous reply: the issue was the order of
the defaults in the range! To fix the problem I just had to:
default "8" if ARM && RCAR3
default "4" if ARM && QEMU
default "4" if ARM && MPSOC
default "256" if X86
default "128" if ARM
> > > > Suggestions are welcome.
> > > > ---
> > > >xen/arch/arm/Kconfig | 2 ++
> > > >xen/arch/arm/platforms/Kconfig | 30 ++
> > > >2 files changed, 32 insertions(+)
> > > >create mode 100644 xen/arch/arm/platforms/Kconfig
> > > >
> > > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > > index a5a6943..b5ddd12 100644
> > > > --- a/xen/arch/arm/Kconfig
> > > > +++ b/xen/arch/arm/Kconfig
> > > > @@ -245,6 +245,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
> > > >config ARM32_HARDEN_BRANCH_PREDICTOR
> > > >def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> > > >+source "arch/arm/platforms/Kconfig"
> > > > +
> > > >source "common/Kconfig"
> > > > source "drivers/Kconfig"
> > > > diff --git a/xen/arch/arm/platforms/Kconfig
> > > > b/xen/arch/arm/platforms/Kconfig
> > > > new file mode 100644
> > > > index 000..0eafbef
> > > > --- /dev/null
> > > > +++ b/xen/arch/arm/platforms/Kconfig
> > > > @@ -0,0 +1,30 @@
> > > > +menu "Platform Support"
> > > > +
> > > > +config QEMU
> > > > + bool "QEMU aarch virt machine support"
> > > > + default n
> > > The default value is confusing here. The default .config will support QEMU
> > > but
> > > not select that.
> > >
> > > While I don't yet buy the argument, some users will also want to remove
> > > platform specific code (Andrii suggest that). This would means by default
> > > support for a specific platform will not be in Xen.
> > >
> > > Furthermore, very likely, the end user will select either one board (e.g
> > > automotive) or all of them (e.g distribution).
> > >
> > > So I think it would be better to do a choice list:
> > > - All -> Board support for all board added. Drivers selected by the
> > > user
> > > - MPSOC -> Select board support for Xilinx + appropriate drivers
> > > - RCAR3 -> Select board support for RCAR3 + appropriate drivers
> > >
> > > The tiny.config would select ALL. This could then be refined by selecting
> > > a
> > > specific platform.
> >
> > The idea of an "ALL" configuration is interesting, however, all the
> > options we would select under "ALL" already default to "Y". Effectively,
> > if we remove the following lines from tiny.config:
> >
> > # CONFIG_GICV3 is not set
> > # CONFIG_MEM_ACCESS is not set
> > # CONFIG_SBSA_VUART_CONSOLE is not set
> > # CONFIG_HAS_NS16550 is not set
> > # CONFIG_HAS_CADENCE_UART is not set
> > # CONFIG_HAS_MVEBU is not set
> > # CONFIG_HAS_PL011 is not set
> > # CONFIG_HAS_SCIF is not set
> > # CONFIG_ARM_SMMU is not set
> >
> > then, it would be as if tiny.config had CONFIG_ALL=y, because after
> > running `make olddefconfig' it would get all these options set to "Y".
> >
> > Given that make olddefconfig is
Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
(sorry for the formatting) On Thu, 31 May 2018, 22:00 Stefano Stabellini, wrote: > On Thu, 31 May 2018, Julien Grall wrote: > > Hi, > > > > On 30/05/18 21:10, Stefano Stabellini wrote: > > > On Wed, 30 May 2018, Julien Grall wrote: > > > > On 05/29/2018 11:34 PM, Stefano Stabellini wrote: > > > > > On Tue, 29 May 2018, Julien Grall wrote: > > > > > > On 25/05/18 21:51, Stefano Stabellini wrote: > > > > > > > On Thu, 24 May 2018, Julien Grall wrote: > > > > > > > > On 23/05/18 23:34, Stefano Stabellini wrote: > > > > > > > > > On Tue, 22 May 2018, Julien Grall > > > I should have read the spec more carefully, thanks for the pointer. > > > Sorry about that. Finally, these patches are starting to make sense :-) > > > > > > All right. I can see why ssbd_state and ssbd_callback_required are > > > separate and their purpose. Aside from adding more info to the commit > > > message, I'll make a couple of different suggestions: > > > > > > 1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state == > > > ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return > > > > early in that case. This will help clarify the intended behavior and > > > mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some > > > cpus. This is just optional, I am fine either way. > > A vendor not able to do a simple return "ARM_SMCCC_NOT_SUPPORTED" in > their > > firmware are not worth to support it in Xen. Most likely, more important > bits > > of that firmware would be broken. > > > > > > > > 2) Can we turn ssbd_callback_required from a this_cpu variable to a > > > single cpu bitmask? It is not great to introduce a new per-cpu varible > > > for just one bit. It would save space and make it easier to access from > > > assembly as a bitmask as it would remove the need for the ldr_this_cpu > > > macro. If I am wrong and the bitmask makes things more complicated > > > rather than simpler, then keep the code as is and just mention it in > the > > > next version of the patch. > > > > I hope you are aware that this will only save 8 byte per-CPU. On most of > > embedded platform you will have less than 16 CPUs. So you would save at > most > > 128 bytes (woah!). If you are that tight in memory, then there are better > > place to reduce the footprint. > > > > I am also not sure to understand the problem of having ldr_this_cpu > around. > > The macro is simple and in any case, you would still require at least a > load > > for the bitmask. > > > > Feel free to suggest an assembly version for the bitmask. > > OK, this is very simple, the first that came to mind, I am sure you can > improve it: > > // 65 is the cpu number, in this example > MOV X1, #65 > > // X1 tells us which doubleword to consider > // X2 has the bit shift for right doubleword > // X3 is the shifted X2, we'll use it to check the bitmask > AND X2, X1, #(64-1) > LSR X1, X1, #3 > MOV X3, #0x1 > LSL X3, X3, X2 > > // we load the pointer to the bitmask in X4 > LDR X4, =cpumask > // increase the pointer to point to the right doubleword > ADD X4, X4, X1 > // load the doubleword > LDR X4, [X4] > // mask with X3, the result is in X1 > AND X1, X4, X3 > Well, because of the SMCC v1.1 convention, you can only use x0-x3. So x4 is a no go. You also cannot use x1 because it contains the enable/disable boolean. Furthermore ldr_this_cpu is only 3 instructions. With your current solution, you have 9 instructions. Even optimized, I honestly doubt you will manage 3 instructions. This is 30% more instructions! So you are maybe going to save few bytes in memory, but everytime you execute the SMC you will lose some time. As this is happening at every entry/exit from EL0, this will have a significant impact on your workload. At this stage, I will keep with the percpu variable. That's the best trade-off between performance and footprint. Cheers, ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
On Thu, 31 May 2018, Julien Grall wrote: > Hi, > > On 30/05/18 21:10, Stefano Stabellini wrote: > > On Wed, 30 May 2018, Julien Grall wrote: > > > On 05/29/2018 11:34 PM, Stefano Stabellini wrote: > > > > On Tue, 29 May 2018, Julien Grall wrote: > > > > > On 25/05/18 21:51, Stefano Stabellini wrote: > > > > > > On Thu, 24 May 2018, Julien Grall wrote: > > > > > > > On 23/05/18 23:34, Stefano Stabellini wrote: > > > > > > > > On Tue, 22 May 2018, Julien Grall > > I should have read the spec more carefully, thanks for the pointer. > > Sorry about that. Finally, these patches are starting to make sense :-) > > > > All right. I can see why ssbd_state and ssbd_callback_required are > > separate and their purpose. Aside from adding more info to the commit > > message, I'll make a couple of different suggestions: > > > > 1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state == > > ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return > > early in that case. This will help clarify the intended behavior and > > mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some > > cpus. This is just optional, I am fine either way. > A vendor not able to do a simple return "ARM_SMCCC_NOT_SUPPORTED" in their > firmware are not worth to support it in Xen. Most likely, more important bits > of that firmware would be broken. > > > > > 2) Can we turn ssbd_callback_required from a this_cpu variable to a > > single cpu bitmask? It is not great to introduce a new per-cpu varible > > for just one bit. It would save space and make it easier to access from > > assembly as a bitmask as it would remove the need for the ldr_this_cpu > > macro. If I am wrong and the bitmask makes things more complicated > > rather than simpler, then keep the code as is and just mention it in the > > next version of the patch. > > I hope you are aware that this will only save 8 byte per-CPU. On most of > embedded platform you will have less than 16 CPUs. So you would save at most > 128 bytes (woah!). If you are that tight in memory, then there are better > place to reduce the footprint. > > I am also not sure to understand the problem of having ldr_this_cpu around. > The macro is simple and in any case, you would still require at least a load > for the bitmask. > > Feel free to suggest an assembly version for the bitmask. OK, this is very simple, the first that came to mind, I am sure you can improve it: // 65 is the cpu number, in this example MOV X1, #65 // X1 tells us which doubleword to consider // X2 has the bit shift for right doubleword // X3 is the shifted X2, we'll use it to check the bitmask AND X2, X1, #(64-1) LSR X1, X1, #3 MOV X3, #0x1 LSL X3, X3, X2 // we load the pointer to the bitmask in X4 LDR X4, =cpumask // increase the pointer to point to the right doubleword ADD X4, X4, X1 // load the doubleword LDR X4, [X4] // mask with X3, the result is in X1 AND X1, X4, X3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>
>>>
>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>
Oleksandr Andrushchenko (8):
xen/grant-table: Make set/clear page private code shared
xen/balloon: Move common memory reservation routines to a module
xen/grant-table: Allow allocating buffers suitable for DMA
xen/gntdev: Allow mappings for DMA buffers
xen/gntdev: Add initial support for dma-buf UAPI
xen/gntdev: Implement dma-buf export functionality
xen/gntdev: Implement dma-buf import functionality
xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
drivers/xen/Kconfig | 23 +
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 +--
drivers/xen/gntdev.c | 1025
-
>>>
>>>
>>> I think this calls for gntdev_dma.c.
>> I assume you mean as a separate file (part of gntdev driver)?
>>> I only had a quick look over gntdev changes but they very much are
>>> concentrated in dma-specific routines.
>>>
>> I tried to do that, but there are some dependencies between the
>> gntdev.c and gntdev_dma.c,
>> so finally I decided to put it all together.
>>> You essentially only share file_operations entry points with
>>> original gntdev code, right?
>>>
>> fops + mappings done by gntdev (struct grant_map) and I need to
>> release map on dma_buf .release
>> callback which makes some cross-dependencies between modules which
>> seemed to be not cute
>> (gntdev keeps its all structs and functions inside, so I cannot
>> easily access those w/o
>> helpers).
>>
>> But I'll try one more time and move all DMA specific stuff into
>> gntdev_dma.c
> Could you please take a quick look at the way I re-structured the
> sources here [1]?
> If this is what you meant.
I looked at final gntdev.c code and I think at least one of the chunks
there ("DMA buffer export support. ") can also be moved out. It still
have a bit too many ifdefs but it looks better to my eye than jamming
everything into a single file (and I think more code can be moved out,
but we can talk about it when you post the patches so that we can see
context).
BTW, I believe it won't build with !CONFIG_XEN_GNTDEV_DMABUF ---
gntdev_remove_map() is defined under this option and is referenced later
without it.
-boris
>
> Thank you,
> Oleksandr
>>> -boris
>>>
>> Thank you,
>> Oleksandr
>>>
drivers/xen/grant-table.c | 176 +-
drivers/xen/mem-reservation.c | 134 +
include/uapi/xen/gntdev.h | 106
include/xen/grant_dev.h | 37 ++
include/xen/grant_table.h | 28 +
include/xen/mem_reservation.h | 29 +
10 files changed, 1527 insertions(+), 103 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/grant_dev.h
create mode 100644 include/xen/mem_reservation.h
>>
> [1]
> https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.8-testing test] 123399: regressions - FAIL
flight 123399 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123399/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 123091 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 123091 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 123091 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 123091 test-xtf-amd64-amd64-47 xen-boot fail REGR. vs. 123091 test-xtf-amd64-amd64-37 xen-boot fail REGR. vs. 123091 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-livepatch 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 123091 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 123091 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 123091 test-amd64-amd64-migrupgrade 11 xen-boot/dst_hostfail REGR. vs. 123091 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 123091 test-amd64-amd64-livepatch7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 123091 test-xtf-amd64-amd64-57 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 123091 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 123091 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 123091 test-xtf-amd64-amd64-17 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 123091 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 123091 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 123091 test-amd64-amd64-xl-qemuu-win7-amd64 7
Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 01:51 AM, Oleksandr Andrushchenko wrote: > On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: >> >> >> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >> >>> >>> Oleksandr Andrushchenko (8): >>> xen/grant-table: Make set/clear page private code shared >>> xen/balloon: Move common memory reservation routines to a module >>> xen/grant-table: Allow allocating buffers suitable for DMA >>> xen/gntdev: Allow mappings for DMA buffers >>> xen/gntdev: Add initial support for dma-buf UAPI >>> xen/gntdev: Implement dma-buf export functionality >>> xen/gntdev: Implement dma-buf import functionality >>> xen/gntdev: Expose gntdev's dma-buf API for in-kernel use >>> >>> drivers/xen/Kconfig | 23 + >>> drivers/xen/Makefile | 1 + >>> drivers/xen/balloon.c | 71 +-- >>> drivers/xen/gntdev.c | 1025 >>> - >> >> >> I think this calls for gntdev_dma.c. > I assume you mean as a separate file (part of gntdev driver)? Yes, source only. The driver stays the same. >> I only had a quick look over gntdev changes but they very much are >> concentrated in dma-specific routines. >> > I tried to do that, but there are some dependencies between the > gntdev.c and gntdev_dma.c, > so finally I decided to put it all together. >> You essentially only share file_operations entry points with original >> gntdev code, right? >> > fops + mappings done by gntdev (struct grant_map) and I need to > release map on dma_buf .release > callback which makes some cross-dependencies between modules which > seemed to be not cute > (gntdev keeps its all structs and functions inside, so I cannot easily > access those w/o > helpers). > > But I'll try one more time and move all DMA specific stuff into > gntdev_dma.c Yes, please try it. Maybe even have gntdev_common.c, gntdev_mem.c (??) and gntdev_dma.c. -boris >> -boris >> > Thank you, > Oleksandr >> >>> drivers/xen/grant-table.c | 176 +- >>> drivers/xen/mem-reservation.c | 134 + >>> include/uapi/xen/gntdev.h | 106 >>> include/xen/grant_dev.h | 37 ++ >>> include/xen/grant_table.h | 28 + >>> include/xen/mem_reservation.h | 29 + >>> 10 files changed, 1527 insertions(+), 103 deletions(-) >>> create mode 100644 drivers/xen/mem-reservation.c >>> create mode 100644 include/xen/grant_dev.h >>> create mode 100644 include/xen/mem_reservation.h >>> > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 3/3] xen-hvm: stop faking I/O to access PCI config space
From: Paul Durrant
This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
requests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
with direct calls to pci_host_config_read/write_common().
Doing so necessitates mapping BDFs to PCIDevices but maintaining a simple
QLIST in xen_device_realize/unrealize() will suffice.
NOTE: whilst config space accesses are currently limited to
PCI_CONFIG_SPACE_SIZE, this patch paves the way to increasing the
limit to PCIE_CONFIG_SPACE_SIZE when Xen gains the ability to
emulate MCFG table accesses.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/i386/xen/trace-events | 2 +
hw/i386/xen/xen-hvm.c| 102 +--
2 files changed, 84 insertions(+), 20 deletions(-)
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 38616b6..8a9077c 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -16,6 +16,8 @@ cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t
addr, uint32_t size) "
cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t
size) "I/O=%p pio write reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr,
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy
dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
+cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size,
uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
+cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size,
uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
# xen-mapcache.c
xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 54f99ab..935a367 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -12,6 +12,7 @@
#include "cpu.h"
#include "hw/pci/pci.h"
+#include "hw/pci/pci_host.h"
#include "hw/i386/pc.h"
#include "hw/i386/apic-msidef.h"
#include "hw/xen/xen_common.h"
@@ -88,6 +89,12 @@ typedef struct XenPhysmap {
static QLIST_HEAD(, XenPhysmap) xen_physmap;
+typedef struct XenPciDevice {
+PCIDevice *pci_dev;
+uint32_t sbdf;
+QLIST_ENTRY(XenPciDevice) entry;
+} XenPciDevice;
+
typedef struct XenIOState {
ioservid_t ioservid;
shared_iopage_t *shared_page;
@@ -108,6 +115,7 @@ typedef struct XenIOState {
struct xs_handle *xenstore;
MemoryListener memory_listener;
MemoryListener io_listener;
+QLIST_HEAD(, XenPciDevice) dev_list;
DeviceListener device_listener;
hwaddr free_phys_offset;
const XenPhysmap *log_for_dirtybit;
@@ -568,6 +576,12 @@ static void xen_device_realize(DeviceListener *listener,
if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
PCIDevice *pci_dev = PCI_DEVICE(dev);
+XenPciDevice *xendev = g_new(XenPciDevice, 1);
+
+xendev->pci_dev = pci_dev;
+xendev->sbdf = PCI_BUILD_BDF(pci_dev_bus_num(pci_dev),
+ pci_dev->devfn);
+QLIST_INSERT_HEAD(>dev_list, xendev, entry);
xen_map_pcidev(xen_domid, state->ioservid, pci_dev);
}
@@ -580,8 +594,17 @@ static void xen_device_unrealize(DeviceListener *listener,
if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
PCIDevice *pci_dev = PCI_DEVICE(dev);
+XenPciDevice *xendev, *next;
xen_unmap_pcidev(xen_domid, state->ioservid, pci_dev);
+
+QLIST_FOREACH_SAFE(xendev, >dev_list, entry, next) {
+if (xendev->pci_dev == pci_dev) {
+QLIST_REMOVE(xendev, entry);
+g_free(xendev);
+break;
+}
+}
}
}
@@ -902,6 +925,62 @@ static void cpu_ioreq_move(ioreq_t *req)
}
}
+static void cpu_ioreq_config(XenIOState *state, ioreq_t *req)
+{
+uint32_t sbdf = req->addr >> 32;
+uint32_t reg = req->addr;
+XenPciDevice *xendev;
+
+if (req->size != sizeof(uint8_t) && req->size != sizeof(uint16_t) &&
+req->size != sizeof(uint32_t)) {
+hw_error("PCI config access: bad size (%u)", req->size);
+}
+
+if (req->count != 1) {
+hw_error("PCI config access: bad count (%u)", req->count);
+}
+
+QLIST_FOREACH(xendev, >dev_list, entry) {
+if (xendev->sbdf != sbdf) {
+continue;
+}
+
+if (!req->data_is_ptr) {
+if (req->dir == IOREQ_READ) {
+req->data = pci_host_config_read_common(
+xendev->pci_dev, reg, PCI_CONFIG_SPACE_SIZE,
+req->size);
+trace_cpu_ioreq_config_read(req, xendev->sbdf, reg,
+req->size, req->data);
+} else if (req->dir == IOREQ_WRITE) {
+
[Xen-devel] [PULL 1/3] xen/hvm: correct reporting of modified memory under physmap during migration
From: Igor Druzhinin
When global_log_dirty is enabled VRAM modification tracking never
worked correctly. The address that is passed to xen_hvm_modified_memory()
is not the effective PFN but RAM block address which is not the same
for VRAM.
We need to make a translation for this address into PFN using
physmap. Since there is no way to access physmap properly inside
xen_hvm_modified_memory() let's make it a global structure.
Signed-off-by: Igor Druzhinin
Acked-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/i386/xen/xen-hvm.c | 37 +++--
hw/i386/xen/xen-mapcache.c| 2 +-
include/sysemu/xen-mapcache.h | 5 ++---
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 6ffa3c2..2afab65 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -86,6 +86,8 @@ typedef struct XenPhysmap {
QLIST_ENTRY(XenPhysmap) list;
} XenPhysmap;
+static QLIST_HEAD(, XenPhysmap) xen_physmap;
+
typedef struct XenIOState {
ioservid_t ioservid;
shared_iopage_t *shared_page;
@@ -107,7 +109,6 @@ typedef struct XenIOState {
MemoryListener memory_listener;
MemoryListener io_listener;
DeviceListener device_listener;
-QLIST_HEAD(, XenPhysmap) physmap;
hwaddr free_phys_offset;
const XenPhysmap *log_for_dirtybit;
@@ -274,14 +275,13 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
MemoryRegion *mr,
g_free(pfn_list);
}
-static XenPhysmap *get_physmapping(XenIOState *state,
- hwaddr start_addr, ram_addr_t size)
+static XenPhysmap *get_physmapping(hwaddr start_addr, ram_addr_t size)
{
XenPhysmap *physmap = NULL;
start_addr &= TARGET_PAGE_MASK;
-QLIST_FOREACH(physmap, >physmap, list) {
+QLIST_FOREACH(physmap, _physmap, list) {
if (range_covers_byte(physmap->start_addr, physmap->size, start_addr))
{
return physmap;
}
@@ -289,23 +289,21 @@ static XenPhysmap *get_physmapping(XenIOState *state,
return NULL;
}
-#ifdef XEN_COMPAT_PHYSMAP
-static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
- ram_addr_t size, void
*opaque)
+static hwaddr xen_phys_offset_to_gaddr(hwaddr phys_offset, ram_addr_t size)
{
-hwaddr addr = start_addr & TARGET_PAGE_MASK;
-XenIOState *xen_io_state = opaque;
+hwaddr addr = phys_offset & TARGET_PAGE_MASK;
XenPhysmap *physmap = NULL;
-QLIST_FOREACH(physmap, _io_state->physmap, list) {
+QLIST_FOREACH(physmap, _physmap, list) {
if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
-return physmap->start_addr;
+return physmap->start_addr + (phys_offset - physmap->phys_offset);
}
}
-return start_addr;
+return phys_offset;
}
+#ifdef XEN_COMPAT_PHYSMAP
static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
{
char path[80], value[17];
@@ -355,7 +353,7 @@ static int xen_add_to_physmap(XenIOState *state,
hwaddr phys_offset = memory_region_get_ram_addr(mr);
const char *mr_name;
-if (get_physmapping(state, start_addr, size)) {
+if (get_physmapping(start_addr, size)) {
return 0;
}
if (size <= 0) {
@@ -384,7 +382,7 @@ go_physmap:
physmap->name = mr_name;
physmap->phys_offset = phys_offset;
-QLIST_INSERT_HEAD(>physmap, physmap, list);
+QLIST_INSERT_HEAD(_physmap, physmap, list);
if (runstate_check(RUN_STATE_INMIGRATE)) {
/* Now when we have a physmap entry we can replace a dummy mapping with
@@ -428,7 +426,7 @@ static int xen_remove_from_physmap(XenIOState *state,
XenPhysmap *physmap = NULL;
hwaddr phys_offset = 0;
-physmap = get_physmapping(state, start_addr, size);
+physmap = get_physmapping(start_addr, size);
if (physmap == NULL) {
return -1;
}
@@ -597,7 +595,7 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
int rc, i, j;
const XenPhysmap *physmap = NULL;
-physmap = get_physmapping(state, start_addr, size);
+physmap = get_physmapping(start_addr, size);
if (physmap == NULL) {
/* not handled */
return;
@@ -1222,7 +1220,7 @@ static void xen_read_physmap(XenIOState *state)
xen_domid, entries[i]);
physmap->name = xs_read(state->xenstore, 0, path, );
-QLIST_INSERT_HEAD(>physmap, physmap, list);
+QLIST_INSERT_HEAD(_physmap, physmap, list);
}
free(entries);
}
@@ -1374,7 +1372,6 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion
**ram_memory)
qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
state->memory_listener = xen_memory_listener;
-QLIST_INIT(>physmap);
memory_listener_register(>memory_listener, _space_memory);
state->log_for_dirtybit = NULL;
@@ -1390,6 +1387,8 @@ void xen_hvm_init(PCMachineState *pcms,
[Xen-devel] [PULL 0/3] xen-20180531-tag
The following changes since commit c181ddaa176856b3cd2dfd12bbcf25fa9c884a97: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180531-1' into staging (2018-05-31 17:00:55 +0100) are available in the git repository at: http://xenbits.xenproject.org/git-http/people/sstabellini/qemu-dm.git tags/xen-20180531-tag for you to fetch changes up to dfb6578d69d60e464be36dafed9741dcfd73d2cf: xen-hvm: stop faking I/O to access PCI config space (2018-05-31 12:05:01 -0700) Xen 2018/05/31 Igor Druzhinin (1): xen/hvm: correct reporting of modified memory under physmap during migration Paul Durrant (2): xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages xen-hvm: stop faking I/O to access PCI config space configure | 5 ++ hw/i386/xen/trace-events | 3 + hw/i386/xen/xen-hvm.c | 205 +++--- hw/i386/xen/xen-mapcache.c| 2 +- include/hw/xen/xen_common.h | 16 include/sysemu/xen-mapcache.h | 5 +- 6 files changed, 179 insertions(+), 57 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PULL 2/3] xen-hvm: try to use xenforeignmemory_map_resource() to map ioreq pages
From: Paul Durrant
Xen 4.11 has a new API to directly map guest resources. Among the resources
that can be mapped using this API are ioreq pages.
This patch modifies QEMU to attempt to use the new API should it exist,
falling back to the previous mechanism if it is unavailable.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
configure | 5
hw/i386/xen/trace-events| 1 +
hw/i386/xen/xen-hvm.c | 66 ++---
include/hw/xen/xen_common.h | 16 +++
4 files changed, 73 insertions(+), 15 deletions(-)
diff --git a/configure b/configure
index a6a4616..be6edc7 100755
--- a/configure
+++ b/configure
@@ -2231,12 +2231,17 @@ EOF
#undef XC_WANT_COMPAT_DEVICEMODEL_API
#define __XEN_TOOLS__
#include
+#include
int main(void) {
xendevicemodel_handle *xd;
+ xenforeignmemory_handle *xfmem;
xd = xendevicemodel_open(0, 0);
xendevicemodel_pin_memory_cacheattr(xd, 0, 0, 0, 0);
+ xfmem = xenforeignmemory_open(0, 0);
+ xenforeignmemory_map_resource(xfmem, 0, 0, 0, 0, 0, NULL, 0, 0);
+
return 0;
}
EOF
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 8dab7bc..38616b6 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -15,6 +15,7 @@ cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t
data_is_ptr, uint64
cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size)
"I/O=%p pio read reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t
size) "I/O=%p pio write reg data=0x%"PRIx64" port=0x%"PRIx64" size=%d"
cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr,
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy
dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d size=%d"
+xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
# xen-mapcache.c
xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 2afab65..54f99ab 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -1237,13 +1237,39 @@ static void xen_wakeup_notifier(Notifier *notifier,
void *data)
static int xen_map_ioreq_server(XenIOState *state)
{
+void *addr = NULL;
+xenforeignmemory_resource_handle *fres;
xen_pfn_t ioreq_pfn;
xen_pfn_t bufioreq_pfn;
evtchn_port_t bufioreq_evtchn;
int rc;
+/*
+ * Attempt to map using the resource API and fall back to normal
+ * foreign mapping if this is not supported.
+ */
+QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_bufioreq != 0);
+QEMU_BUILD_BUG_ON(XENMEM_resource_ioreq_server_frame_ioreq(0) != 1);
+fres = xenforeignmemory_map_resource(xen_fmem, xen_domid,
+ XENMEM_resource_ioreq_server,
+ state->ioservid, 0, 2,
+ ,
+ PROT_READ | PROT_WRITE, 0);
+if (fres != NULL) {
+trace_xen_map_resource_ioreq(state->ioservid, addr);
+state->buffered_io_page = addr;
+state->shared_page = addr + TARGET_PAGE_SIZE;
+} else if (errno != EOPNOTSUPP) {
+error_report("failed to map ioreq server resources: error %d
handle=%p",
+ errno, xen_xc);
+return -1;
+}
+
rc = xen_get_ioreq_server_info(xen_domid, state->ioservid,
- _pfn, _pfn,
+ (state->shared_page == NULL) ?
+ _pfn : NULL,
+ (state->buffered_io_page == NULL) ?
+ _pfn : NULL,
_evtchn);
if (rc < 0) {
error_report("failed to get ioreq server info: error %d handle=%p",
@@ -1251,27 +1277,37 @@ static int xen_map_ioreq_server(XenIOState *state)
return rc;
}
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
-DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-
-state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
- PROT_READ | PROT_WRITE,
- 1, _pfn, NULL);
if (state->shared_page == NULL) {
-error_report("map shared IO page returned error %d handle=%p",
- errno, xen_xc);
-return -1;
+DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+
+state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
+ PROT_READ | PROT_WRITE,
+ 1, _pfn, NULL);
+if (state->shared_page == NULL) {
+error_report("map shared
[Xen-devel] [linux-4.9 bisection] complete test-amd64-amd64-xl-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-xsm testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Bug introduced: 944e0fc51a89c9827b98813d65dc083274777c7f Bug not present: b2d748b3a8d4e936a7e6e5fc9f04e2f9696efcc5 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/123474/ commit 944e0fc51a89c9827b98813d65dc083274777c7f Author: David Woodhouse Date: Sun May 20 20:51:10 2018 +0100 x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen commit def9331a1290cc6132d79f8e6565871e8e38 upstream When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem. The proper solution is to never set the bit in case of Xen. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Acked-by: Thomas Gleixner Signed-off-by: Juergen Gross Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.9/test-amd64-amd64-xl-xsm.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-4.9/test-amd64-amd64-xl-xsm.xen-boot --summary-out=tmp/123474.bisection-summary --basis-template=122969 --blessings=real,real-bisect linux-4.9 test-amd64-amd64-xl-xsm xen-boot Searching for failure / basis pass: 123350 fail [host=pinot0] / 122969 [host=huxelrebe0] 122893 [host=chardonnay1] 122824 [host=elbling1] 122564 [host=huxelrebe0] 122519 [host=elbling1] 122398 [host=chardonnay0] 122289 ok. Failure / basis pass flights: 123350 / 122289 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest aa4b4ace9ce02cf164e0982739e9565d6214cfa9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a fc5805daef091240cd5fc06634a8bcdb2f3bb843 Basis pass cc0eb4dd504b8a0adab865a9488297aca63013ba c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 82540b66ceb9318aa185f2488cbbbe479694de8f Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#cc0eb4dd504b8a0adab865a9488297aca63013ba-aa4b4ace9ce02cf164e0982739e9565d6214cfa9 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60 git://xenbits.xen.org/qemu-xen.git#5c3fdee026a204a59cb392e43a313ab558de9682-43139135a8938de44f66333831d3a8655d07663a git://xenbits.xen.org/xen.git#82540b66ceb9318aa185f2488cbbbe479694de8f-fc5805daef091240cd5fc06634a8bcdb2f3bb843 Loaded 3004 nodes in revision graph Searching for test results: 122272 [host=elbling1] 122289 pass cc0eb4dd504b8a0adab865a9488297aca63013ba c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 82540b66ceb9318aa185f2488cbbbe479694de8f 122398 [host=chardonnay0] 122519 [host=elbling1] 122564 [host=huxelrebe0] 122824 [host=elbling1] 122893 [host=chardonnay1] 122969 [host=huxelrebe0] 123074 fail irrelevant 123150 fail irrelevant 123209 fail irrelevant 123257 fail aa4b4ace9ce02cf164e0982739e9565d6214cfa9 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a fc5805daef091240cd5fc06634a8bcdb2f3bb843 123298 fail aa4b4ace9ce02cf164e0982739e9565d6214cfa9 c530a75c1e6a472b0eb9558310b518f0dfcd8860
[Xen-devel] [linux-3.18 test] 123396: regressions - FAIL
flight 123396 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123396/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 123274 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 123274 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123274 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123274 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123274 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123274 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123274 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123274 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123274 build-arm64-pvops 6 kernel-build fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linux8eb1ef076bab4bd4975922a06bdffa3d40c4197c baseline version: linuxb87af3ab9dae0dc53b201701725ed6e2af4f2f74 Last test of basis 123274 2018-05-27 22:03:44 Z3 days Testing same since 123396 2018-05-30 06:10:32 Z1 days1 attempts People who touched revisions under test: "Huang, Ying" Aaro Koskinen Aaron Brown Al Viro Alan Stern
Re: [Xen-devel] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
On 31/05/18 17:29, Juergen Gross wrote: >On 31/05/18 16:49, Andrew Cooper wrote: >> On 31/05/18 15:14, Juergen Gross wrote: >>> On 31/05/18 15:05, Marcello Seri wrote: When xenstore was updated to support safe-string, some unnecessary copies were introduced. A further patch reduced the copies at the price of many calls to unsafe conversions between bytes and strings. In the port we also did not notice that some C stubs were still incorrectly using ocaml strings as mutable payload. This set of patches updates the C stubs that use mutable payloads passed from ocaml, and reduces the amount of unsafe conversions where possible without further increasing the number of copies. This seems also to fix some unclear instabilities that appeared after the former patch introducing the unsafe conversion with some version of the ocaml compiler. >>> This is rather vague. Unfortunately I don't know exactly what fixed the issue. My belief is that the first patch fixed it. The second patch contains both changes to use the changes from the first patch and changes to remove further uses of unsafe conversions. I could try to test them separately, and see if the first plus a small part of the second is enough, but I will no longer be able to access the test environment starting from tomorrow as I am changing jobs and the tests are very slow to run. >>> Can you confirm that oxenstored is now as stable as it was without the >>> safe-string patches? >>> >>> Could you please mention the commit of the patch you are fixing in the >>> related commit message? I'd like to know which of the two patches is >>> the real fix and which is "only" some improvement of code. >>> >>> We are rather close to the release, so I'm hesitating to accept cleanup >>> patches now. >> So far, these changes do appear to have fixed the issues XenRT first >> noticed. Unfortunately the failures are very hard to quantify, but seem >> to amount to "some operations seem to get dropped" (as there is no >> obvious corruption), but the issues are rare and takes an large quantity >> of machine hours to encounter. > Did you try multiple concurrent runs of "xs-test -r " to > reproduce the problem? This has helped me a lot to find problems in > xenstore. No, I did not know about it. I will setup a machine with these changes and test it. Thanks! Indeed, xs-test shows a failure on the unpatched version. >> I can't comment for exact changes, but the bug being fixed by patch 1 is >> not passing a buffer (which the Ocaml runtime thinks is immutable) to >> the C stubs to be written into. AFAICT, it is consequence of the very >> first attempt to move from mutable to immutable strings. > So patch 2 is more kind of a cleanup? Or is it needed for the fix, too? This is not just a cleanup, as it contains changes to adapt to the new xb interface. I think it would be safer to include this patch anyways because it reduces the calls to unsafe conversion functions, further reducing the surface for potential issues. Marcello ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 123395: regressions - trouble: broken/fail/pass
flight 123395 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123395/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-migrupgrade 11 xen-boot/dst_hostfail REGR. vs. 123122 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-livepatch 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 123122 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 123122 test-xtf-amd64-amd64-57 xen-boot fail REGR. vs. 123122 test-xtf-amd64-amd64-17 xen-boot fail REGR. vs. 123122 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 123122 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 123122 test-xtf-amd64-amd64-27 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-xtf-amd64-amd64-47 xen-boot fail REGR. vs. 123122 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 123122 test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123122 test-amd64-i386-migrupgrade 11 xen-boot/dst_hostfail REGR. vs. 123122 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 123122 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-livepatch7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 123122 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 123122 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 123122 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 123122 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 123122 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123122 test-xtf-amd64-amd64-37 xen-boot fail REGR.
Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
On 5/30/2018 10:10 PM, Manish Jaggi wrote:
>
>
> On 05/31/2018 01:16 AM, Sameer Goel wrote:
>> Manish, I'll take another look at the variable names. I might not have
>> enough time :).
On 05/23/2018 10:48 PM, Manish Jaggi wrote:
> Hi Sameer,
>
> General Comment, please use appropriate variable names for XXX_domain
> structures in code which is xen specific.
I thought that we had discussed this before on one of the RFCs.
>>> Yes and no one replied to my last comment that the var names have to be non
>>> confusing in Xen specific code.
>> I'm sorry about that. I just assumed that since the policy on ported
>> variable names was consistent we so not nee to change the names.
>>
At this point we are just using the format used for smmu-v2.
>>> smmu-v2 has a lot of confusing variable names with _domain.
>>> I believe that file needs to be fixed as well.
I don't think that the variable names are inappropriate. Unless there is a
very specific issue with the variable names,
>>> The issue is in code readability and understanding the flow.
>>> It is confusing so many _domain variable names are used which are not
>>> verbose.
>> These names are coming from the original Linux code. So, we do not change
>> them as per the policy. That being said I can add a comment section to
>> explain the confusing variables in the Xen specific code? Please let me know
>> if this will help us resolve this issue?
>>
> If it is in Xen specific functions, then it can be changed, this is what
> julien also confirmed.
Agreed. Changing the var names.
>
>>> Two functions different and confusing variable names
>> + struct iommu_domain *domain;
>> +};
>> +
> As this is a xen specific code, can the variable names be used
> appropriately.
> Repeating my comment from earlier version.
> a domain is usually a VM in Xen. So it is a bit confusing to use domain
> for iommu_domain.
>> The struct is fine but you have an issue with the var name right?
> Yes.
>>
>> +/*
>> + * Xen: io_pgtable compatibility defines.
>> + * Most of these are to port in the S1 translation code as is.
>> + */
>> +struct io_pgtable_ops {
>> +};
>> +
>> +struct iommu_gather_ops {
>> + void (*tlb_flush_all)(void *cookie);
>> + void (*tlb_add_flush)(unsigned long iova, size_t size, size_t
>> granule,
>> + bool leaf, void *cookie);
>> + void (*tlb_sync)(void *cookie);
>> +};
>> +
>> +struct io_pgtable_cfg {
>> + /*
>> + * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
>> + * stage 1 PTEs, for hardware which insists on validating them
>> + * even in non-secure state where they should normally be
>> ignored.
>> + *
>> + * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
>> + * IOMMU_NOEXEC flags and map everything with full access, for
>> + * hardware which does not implement the permissions of a given
>> + * format, and/or requires some format-specific default value.
>> + *
>> + * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching
>> invalid
>> + * (unmapped) entries but the hardware might do so anyway,
>> perform
>> + * TLB maintenance when mapping as well as when unmapping.
>> + *
>> + * IO_PGTABLE_QUIRK_ARM_MTK_4GB: (ARM v7s format) Set bit 9 in all
>> + * PTEs, for Mediatek IOMMUs which treat it as a 33rd address bit
>> + * when the SoC is in "4GB mode" and they can only access the
>> high
>> + * remap of DRAM (0x1_ to 0x1_).
>> + *
>> + * IO_PGTABLE_QUIRK_NO_DMA: Guarantees that the tables will only
>> ever
>> + * be accessed by a fully cache-coherent IOMMU or CPU (e.g. for a
>> + * software-emulated IOMMU), such that pagetable updates need not
>> + * be treated as explicit DMA data.
>> + */
>> + #define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
>> + #define IO_PGTABLE_QUIRK_NO_PERMS BIT(1)
>> + #define IO_PGTABLE_QUIRK_TLBI_ON_MAP BIT(2)
>> + #define IO_PGTABLE_QUIRK_ARM_MTK_4GB BIT(3)
>> + #define IO_PGTABLE_QUIRK_NO_DMA BIT(4)
>> + unsigned long quirks;
>> + unsigned long pgsize_bitmap;
>> + unsigned int ias;
>> + unsigned int oas;
>> + const struct iommu_gather_ops *tlb;
>> + struct device *iommu_dev;
>> +
>> + /* Low-level data specific to the table format */
>> + union {
>> + struct {
>> + u64 ttbr[2];
>> + u64 tcr;
>> + u64 mair[2];
>> + } arm_lpae_s1_cfg;
>> +
>> + struct {
>> + u64 vttbr;
>>
[Xen-devel] [PATCH for-4.11] x86/VT-x: Fix printing of EFER in vmcs_dump_vcpu()
This is essentially a "take 2" of c/s 82540b66ce "x86/VT-x: Fix determination
of EFER.LMA in vmcs_dump_vcpu()" because in hindight, that change was more
problematic than useful.
The original reason was to fix the logic for determining when not to print the
PDPTE pointers. However, mutating the efer variable (particularly LME and
LMA) before printing it interferes with diagnosing vmentry failures.
Instead of modifying efer, change the PDPTE conditional to use
VM_ENTRY_IA32E_MODE.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: Juergen Gross
This wants taking for 4.11. It is zero risk for running VMs, but fixes a
regression in the diagnostics of crashed VMs.
---
xen/arch/x86/hvm/vmx/vmcs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 70c2fb7..b783ff0 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1788,10 +1788,7 @@ void vmcs_dump_vcpu(struct vcpu *v)
vmentry_ctl = vmr32(VM_ENTRY_CONTROLS),
vmexit_ctl = vmr32(VM_EXIT_CONTROLS);
cr4 = vmr(GUEST_CR4);
-
-/* EFER.LMA is read as zero, and is loaded from vmentry_ctl on entry. */
-BUILD_BUG_ON(VM_ENTRY_IA32E_MODE << 1 != EFER_LMA);
-efer = vmr(GUEST_EFER) | ((vmentry_ctl & VM_ENTRY_IA32E_MODE) << 1);
+efer = vmr(GUEST_EFER);
printk("*** Guest State ***\n");
printk("CR0: actual=0x%016lx, shadow=0x%016lx, gh_mask=%016lx\n",
@@ -1801,7 +1798,7 @@ void vmcs_dump_vcpu(struct vcpu *v)
printk("CR3 = 0x%016lx\n", vmr(GUEST_CR3));
if ( (v->arch.hvm_vmx.secondary_exec_control &
SECONDARY_EXEC_ENABLE_EPT) &&
- (cr4 & X86_CR4_PAE) && !(efer & EFER_LMA) )
+ (cr4 & X86_CR4_PAE) && !(vmentry_ctl & VM_ENTRY_IA32E_MODE) )
{
printk("PDPTE0 = 0x%016lx PDPTE1 = 0x%016lx\n",
vmr(GUEST_PDPTE(0)), vmr(GUEST_PDPTE(1)));
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
On 5/30/2018 10:13 PM, Manish Jaggi wrote:
>
>
> On 05/31/2018 04:31 AM, Sameer Goel wrote:
>> +
>> +static int arm_smmu_iommu_domain_init(struct domain *d)
> Where is iommu_domain initialized?
> The function does not use a iommu_domain * variable
>> Please check iommu.c 2 levels up.
> In this function do you see iommu_domain getting allocated or initialized?
> As per the name of function arm_smmu iommu_domain_init.
> Where is init of iommu_domain in this function?
Well without the xen_domain the iommu_domain is not initialized. It is just the
default value. This generic iommu code makes an .init call to our code for
whatever initialization is needed. So the name here seemed absolutely fine to
me.
Initialization does not always refer to allocation. In this case this is driver
specific initialization. Since, the iommu code is making an init call to the
smmu code hence the name arm_smmu_iommu_domain_init. So, again I agree with
your comments on the domain variable names and I'm making these changes as they
would make the code cleaner. This function name change probably will not do
much but the move along the discussion, let me know what you were thinking.
>
> +static int arm_smmu_iommu_domain_init(struct domain *d)
> +{
> + struct arm_smmu_xen_domain *xen_domain;
> +
> + xen_domain = xzalloc(struct arm_smmu_xen_domain);
> + if (!xen_domain)
> + return -ENOMEM;
> +
> + spin_lock_init(_domain->lock);
> + INIT_LIST_HEAD(_domain->contexts);
> +
> + dom_iommu(d)->arch.priv = xen_domain;
> +
> + return 0;
> +}
> +
>
>
>
>> Thanks,
>> Sameer
>>>
>>> ___
>>> Xen-devel mailing list
>>> Xen-devel@lists.xenproject.org
>>> https://lists.xenproject.org/mailman/listinfo/xen-devel
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
As we recently found out in another project with C bindings, problems stemming from interaction with the OCaml garbage collector can be very rare and very hard to find. So I appreciate to get this right and Marcello (who is sitting next to me) has the most experience with this in our group. But if we have doubts that this is correct, we maybe should not include this into the next release and test the patches for immutable strings (including this series) for the release after this. These patches do look good to me. — Christian > On 31 May 2018, at 16:29, Juergen Gross wrote: > > On 31/05/18 16:49, Andrew Cooper wrote: >> On 31/05/18 15:14, Juergen Gross wrote: >>> On 31/05/18 15:05, Marcello Seri wrote: When xenstore was updated to support safe-string, some unnecessary copies were introduced. A further patch reduced the copies at the price of many calls to unsafe conversions between bytes and strings. In the port we also did not notice that some C stubs were still incorrectly using ocaml strings as mutable payload. This set of patches updates the C stubs that use mutable payloads passed from ocaml, and reduces the amount of unsafe conversions where possible without further increasing the number of copies. This seems also to fix some unclear instabilities that appeared after the former patch introducing the unsafe conversion with some version of the ocaml compiler. >>> This is rather vague. >>> >>> Can you confirm that oxenstored is now as stable as it was without the >>> safe-string patches? >>> >>> Could you please mention the commit of the patch you are fixing in the >>> related commit message? I'd like to know which of the two patches is >>> the real fix and which is "only" some improvement of code. >>> >>> We are rather close to the release, so I'm hesitating to accept cleanup >>> patches now. >> >> So far, these changes do appear to have fixed the issues XenRT first >> noticed. Unfortunately the failures are very hard to quantify, but seem >> to amount to "some operations seem to get dropped" (as there is no >> obvious corruption), but the issues are rare and takes an large quantity >> of machine hours to encounter. > > Did you try multiple concurrent runs of "xs-test -r " to > reproduce the problem? This has helped me a lot to find problems in > xenstore. > >> I can't comment for exact changes, but the bug being fixed by patch 1 is >> not passing a buffer (which the Ocaml runtime thinks is immutable) to >> the C stubs to be written into. AFAICT, it is consequence of the very >> first attempt to move from mutable to immutable strings. > > So patch 2 is more kind of a cleanup? Or is it needed for the fix, too? > > > Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
On 31/05/18 16:49, Andrew Cooper wrote: > On 31/05/18 15:14, Juergen Gross wrote: >> On 31/05/18 15:05, Marcello Seri wrote: >>> When xenstore was updated to support safe-string, some unnecessary >>> copies were introduced. A further patch reduced the copies at the price >>> of many calls to unsafe conversions between bytes and strings. In the >>> port we also did not notice that some C stubs were still incorrectly >>> using ocaml strings as mutable payload. >>> >>> This set of patches updates the C stubs that use mutable payloads passed >>> from ocaml, and reduces the amount of unsafe conversions where possible >>> without further increasing the number of copies. >>> >>> This seems also to fix some unclear instabilities that appeared after >>> the former patch introducing the unsafe conversion with some version of >>> the ocaml compiler. >> This is rather vague. >> >> Can you confirm that oxenstored is now as stable as it was without the >> safe-string patches? >> >> Could you please mention the commit of the patch you are fixing in the >> related commit message? I'd like to know which of the two patches is >> the real fix and which is "only" some improvement of code. >> >> We are rather close to the release, so I'm hesitating to accept cleanup >> patches now. > > So far, these changes do appear to have fixed the issues XenRT first > noticed. Unfortunately the failures are very hard to quantify, but seem > to amount to "some operations seem to get dropped" (as there is no > obvious corruption), but the issues are rare and takes an large quantity > of machine hours to encounter. Did you try multiple concurrent runs of "xs-test -r " to reproduce the problem? This has helped me a lot to find problems in xenstore. > I can't comment for exact changes, but the bug being fixed by patch 1 is > not passing a buffer (which the Ocaml runtime thinks is immutable) to > the C stubs to be written into. AFAICT, it is consequence of the very > first attempt to move from mutable to immutable strings. So patch 2 is more kind of a cleanup? Or is it needed for the fix, too? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
On 31/05/18 15:14, Juergen Gross wrote: > On 31/05/18 15:05, Marcello Seri wrote: >> When xenstore was updated to support safe-string, some unnecessary >> copies were introduced. A further patch reduced the copies at the price >> of many calls to unsafe conversions between bytes and strings. In the >> port we also did not notice that some C stubs were still incorrectly >> using ocaml strings as mutable payload. >> >> This set of patches updates the C stubs that use mutable payloads passed >> from ocaml, and reduces the amount of unsafe conversions where possible >> without further increasing the number of copies. >> >> This seems also to fix some unclear instabilities that appeared after >> the former patch introducing the unsafe conversion with some version of >> the ocaml compiler. > This is rather vague. > > Can you confirm that oxenstored is now as stable as it was without the > safe-string patches? > > Could you please mention the commit of the patch you are fixing in the > related commit message? I'd like to know which of the two patches is > the real fix and which is "only" some improvement of code. > > We are rather close to the release, so I'm hesitating to accept cleanup > patches now. So far, these changes do appear to have fixed the issues XenRT first noticed. Unfortunately the failures are very hard to quantify, but seem to amount to "some operations seem to get dropped" (as there is no obvious corruption), but the issues are rare and takes an large quantity of machine hours to encounter. I can't comment for exact changes, but the bug being fixed by patch 1 is not passing a buffer (which the Ocaml runtime thinks is immutable) to the C stubs to be written into. AFAICT, it is consequence of the very first attempt to move from mutable to immutable strings. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote: On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality xen/gntdev: Expose gntdev's dma-buf API for in-kernel use drivers/xen/Kconfig | 23 + drivers/xen/Makefile | 1 + drivers/xen/balloon.c | 71 +-- drivers/xen/gntdev.c | 1025 - I think this calls for gntdev_dma.c. I assume you mean as a separate file (part of gntdev driver)? I only had a quick look over gntdev changes but they very much are concentrated in dma-specific routines. I tried to do that, but there are some dependencies between the gntdev.c and gntdev_dma.c, so finally I decided to put it all together. You essentially only share file_operations entry points with original gntdev code, right? fops + mappings done by gntdev (struct grant_map) and I need to release map on dma_buf .release callback which makes some cross-dependencies between modules which seemed to be not cute (gntdev keeps its all structs and functions inside, so I cannot easily access those w/o helpers). But I'll try one more time and move all DMA specific stuff into gntdev_dma.c Could you please take a quick look at the way I re-structured the sources here [1]? If this is what you meant. Thank you, Oleksandr -boris Thank you, Oleksandr drivers/xen/grant-table.c | 176 +- drivers/xen/mem-reservation.c | 134 + include/uapi/xen/gntdev.h | 106 include/xen/grant_dev.h | 37 ++ include/xen/grant_table.h | 28 + include/xen/mem_reservation.h | 29 + 10 files changed, 1527 insertions(+), 103 deletions(-) create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/grant_dev.h create mode 100644 include/xen/mem_reservation.h [1] https://github.com/andr2000/linux/commits/xen_tip_linux_next_xen_dma_buf_v2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality
On 05/31/2018 08:55 AM, Oleksandr Andrushchenko wrote:
On 05/31/2018 02:10 AM, Dongwon Kim wrote:
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file
descriptor
does not exist or has already been released, then -ENOENT is
returned.
For valid file descriptors this must not be treated as error.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 478
++-
1 file changed, 476 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 9e450622af1a..52abc6cd5846 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -4,6 +4,8 @@
* Device for accessing (in user-space) pages that have been
granted by other
* domains.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2006-2007, D G Murray.
* (c) 2009 Gerd Hoffmann
* (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
@@ -41,6 +43,9 @@
#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
#include
#endif
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+#include
+#endif
#include
#include
@@ -81,6 +86,17 @@ struct gntdev_priv {
/* Device for which DMA memory is allocated. */
struct device *dma_dev;
#endif
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ /* Private data of the hyper DMA buffers. */
+
+ /* List of exported DMA buffers. */
+ struct list_head dmabuf_exp_list;
+ /* List of wait objects. */
+ struct list_head dmabuf_exp_wait_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex dmabuf_lock;
+#endif
};
struct unmap_notify {
@@ -125,12 +141,38 @@ struct grant_map {
#ifdef CONFIG_XEN_GNTDEV_DMABUF
struct xen_dmabuf {
+ struct gntdev_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+ struct grant_map *map;
+ } exp;
struct {
/* Granted references of the imported buffer. */
grant_ref_t *refs;
} imp;
} u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct xen_dmabuf_wait_obj {
+ struct list_head next;
+ struct xen_dmabuf *xen_dmabuf;
+ struct completion completion;
+};
+
+struct xen_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
};
#endif
@@ -320,6 +362,16 @@ static void gntdev_put_map(struct gntdev_priv
*priv, struct grant_map *map)
gntdev_free_map(map);
}
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+static void gntdev_remove_map(struct gntdev_priv *priv, struct
grant_map *map)
+{
+ mutex_lock(>lock);
+ list_del(>next);
+ gntdev_put_map(NULL /* already removed */, map);
+ mutex_unlock(>lock);
+}
+#endif
+
/*
-- */
static int find_grant_ptes(pte_t *pte, pgtable_t token,
@@ -628,6 +680,12 @@ static int gntdev_open(struct inode *inode,
struct file *flip)
INIT_LIST_HEAD(>freeable_maps);
mutex_init(>lock);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ mutex_init(>dmabuf_lock);
+ INIT_LIST_HEAD(>dmabuf_exp_list);
+ INIT_LIST_HEAD(>dmabuf_exp_wait_list);
+#endif
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -1053,17 +,433 @@ static long gntdev_ioctl_grant_copy(struct
gntdev_priv *priv, void __user *u)
/* DMA buffer export
support. */
/*
-- */
+/*
-- */
+/* Implementation of wait for exported DMA buffer to be
released. */
+/*
-- */
+
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct xen_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_priv *priv,
+ struct xen_dmabuf *xen_dmabuf)
+{
+ struct xen_dmabuf_wait_obj *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ init_completion(>completion);
+ obj->xen_dmabuf =
Re: [Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/31/2018 10:51 AM, Oleksandr Andrushchenko wrote:
On 05/30/2018 10:24 PM, Boris Ostrovsky wrote:
On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote:
On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
BTW, I also think you can further simplify
xenmem_reservation_va_mapping_* routines by bailing out right away if
xen_feature(XENFEAT_auto_translated_physmap). In fact, you might even
make them inlines, along the lines of
inline void xenmem_reservation_va_mapping_reset(unsigned long count,
struct page **pages)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap))
__xenmem_reservation_va_mapping_reset(...)
#endif
}
How about:
#ifdef CONFIG_XEN_HAVE_PVMMU
static inline __xenmem_reservation_va_mapping_reset(struct page *page)
{
[...]
}
#endif
and
void xenmem_reservation_va_mapping_reset(unsigned long count,
struct page **pages)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
int i;
for (i = 0; i < count; i++)
__xenmem_reservation_va_mapping_reset(pages[i]);
}
#endif
}
This way I can use __xenmem_reservation_va_mapping_reset(page);
instead of xenmem_reservation_va_mapping_reset(1, );
Sure, this also works.
Could you please take look at the patch attached if this is what we want?
Please ignore it, it is ugly ;)
I have implemented this as you suggested:
static inline void
xenmem_reservation_va_mapping_update(unsigned long count,
struct page **pages,
xen_pfn_t *frames)
{
#ifdef CONFIG_XEN_HAVE_PVMMU
if (!xen_feature(XENFEAT_auto_translated_physmap))
__xenmem_reservation_va_mapping_update(count, pages, frames);
#endif
}
-boris
Thank you,
Oleksandr
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
On 31/05/18 15:05, Marcello Seri wrote: > When xenstore was updated to support safe-string, some unnecessary > copies were introduced. A further patch reduced the copies at the price > of many calls to unsafe conversions between bytes and strings. In the > port we also did not notice that some C stubs were still incorrectly > using ocaml strings as mutable payload. > > This set of patches updates the C stubs that use mutable payloads passed > from ocaml, and reduces the amount of unsafe conversions where possible > without further increasing the number of copies. > > This seems also to fix some unclear instabilities that appeared after > the former patch introducing the unsafe conversion with some version of > the ocaml compiler. This is rather vague. Can you confirm that oxenstored is now as stable as it was without the safe-string patches? Could you please mention the commit of the patch you are fixing in the related commit message? I'd like to know which of the two patches is the real fix and which is "only" some improvement of code. We are rather close to the release, so I'm hesitating to accept cleanup patches now. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11 2/2] ocaml/xenstored: reduce use of unsafe conversions
The rationalisation of the Xs_ring interface in the xb library allows to further reduce the unsafe calls withouth introducing copies. This patch also contains some further code cleanups. Signed-off-by: Marcello Seri --- tools/ocaml/xenstored/logging.ml | 16 ++-- tools/ocaml/xenstored/stdext.ml | 2 +- tools/ocaml/xenstored/utils.ml | 9 - 3 files changed, 11 insertions(+), 16 deletions(-) diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml index 45a2c222e6..ea6033195d 100644 --- a/tools/ocaml/xenstored/logging.ml +++ b/tools/ocaml/xenstored/logging.ml @@ -252,13 +252,11 @@ let string_of_access_type = function *) let sanitize_data data = - let data = Bytes.copy data in - for i = 0 to Bytes.length data - 1 - do - if Bytes.get data i = '\000' then - Bytes.set data i ' ' - done; - String.escaped (Bytes.unsafe_to_string data) + let data = String.init + (String.length data) + (fun i -> let c = data.[i] in if c = '\000' then ' ' else c) + in + String.escaped data let activate_access_log = ref true let access_log_destination = ref (File (Paths.xen_log_dir ^ "/xenstored-access.log")) @@ -291,9 +289,7 @@ let access_logging ~con ~tid ?(data="") ~level access_type = let date = string_of_date() in let tid = string_of_tid ~con tid in let access_type = string_of_access_type access_type in - (* we can use unsafe_of_string here as the sanitize_data function - immediately makes a copy of the data and operates on that. *) - let data = sanitize_data (Bytes.unsafe_of_string data) in + let data = sanitize_data data in let prefix = prefix !access_log_destination date in let msg = Printf.sprintf "%s %s %s %s" prefix tid access_type data in logger.write ~level msg) diff --git a/tools/ocaml/xenstored/stdext.ml b/tools/ocaml/xenstored/stdext.ml index 869fec36f2..305a330aa5 100644 --- a/tools/ocaml/xenstored/stdext.ml +++ b/tools/ocaml/xenstored/stdext.ml @@ -122,7 +122,7 @@ let pidfile_write filename = let pid = Unix.getpid () in let buf = string_of_int pid ^ "\n" in let len = String.length buf in - if Unix.write fd (Bytes.unsafe_of_string buf) 0 len <> len + if Unix.write_substring fd buf 0 len <> len then failwith "pidfile_write failed"; ) (fun () -> Unix.close fd) diff --git a/tools/ocaml/xenstored/utils.ml b/tools/ocaml/xenstored/utils.ml index 73affb7ea4..b252db799b 100644 --- a/tools/ocaml/xenstored/utils.ml +++ b/tools/ocaml/xenstored/utils.ml @@ -46,12 +46,11 @@ let get_hierarchy path = let hexify s = let hexseq_of_char c = sprintf "%02x" (Char.code c) in let hs = Bytes.create (String.length s * 2) in - for i = 0 to String.length s - 1 - do - let seq = hexseq_of_char s.[i] in + String.iteri (fun i c -> + let seq = hexseq_of_char c in Bytes.set hs (i * 2) seq.[0]; Bytes.set hs (i * 2 + 1) seq.[1]; - done; + ) s; Bytes.unsafe_to_string hs let unhexify hs = @@ -84,7 +83,7 @@ let create_unix_socket name = let read_file_single_integer filename = let fd = Unix.openfile filename [ Unix.O_RDONLY ] 0o640 in - let buf = Bytes.make 20 (char_of_int 0) in + let buf = Bytes.make 20 '\000' in let sz = Unix.read fd buf 0 20 in Unix.close fd; int_of_string (Bytes.sub_string buf 0 sz) -- 2.17.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11 1/2] ocaml/libs/xb: use bytes in place of strings for mutable buffers
Since ocaml 4.06.0, that made safe-string on by default, the compiler is allowed to perform optimisations on immutable strings. They should no longer be used as mutable buffers, and bytes should be used instead. The c stubs for Xs_ring have been updated to use bytes, and the interface rationalised mimicking the new Unix module in the standard library (the implementation of Unix.write_substring uses unsafe_of_string in the exact same way, and both the write implementations are using the bytes as an immutable payload for the write). Signed-off-by: Marcello Seri --- tools/ocaml/libs/xb/xb.ml | 12 +--- tools/ocaml/libs/xb/xb.mli | 2 +- tools/ocaml/libs/xb/xs_ring.ml | 12 +++- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml index 660224f895..ca738657df 100644 --- a/tools/ocaml/libs/xb/xb.ml +++ b/tools/ocaml/libs/xb/xb.ml @@ -76,9 +76,9 @@ let read_fd back con b len = rd let read_mmap back con b len = - let s = String.make len (char_of_int 0) in + let s = Bytes.make len '\000' in let rd = Xs_ring.read back.mmap s len in - Bytes.blit_string s 0 b 0 rd; + Bytes.blit s 0 b 0 rd; back.work_again <- (rd > 0); if rd > 0 then back.eventchn_notify (); @@ -90,19 +90,17 @@ let read con b len = | Xenmmap backmmap -> read_mmap backmmap con b len let write_fd back con b len = - Unix.write back.fd b 0 len + Unix.write_substring back.fd b 0 len let write_mmap back con s len = - let ws = Xs_ring.write back.mmap s len in + let ws = Xs_ring.write_substring back.mmap s len in if ws > 0 then back.eventchn_notify (); ws let write con s len = match con.backend with - (* we can use unsafe_of_string here as the bytes are used immutably - in the Unix.write operation. *) - | Fd backfd -> write_fd backfd con (Bytes.unsafe_of_string s) len + | Fd backfd -> write_fd backfd con s len | Xenmmap backmmap -> write_mmap backmmap con s len (* NB: can throw Reconnect *) diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli index d566011fc7..3a00da6cdd 100644 --- a/tools/ocaml/libs/xb/xb.mli +++ b/tools/ocaml/libs/xb/xb.mli @@ -79,7 +79,7 @@ val queue : t -> Packet.t -> unit val read_fd : backend_fd -> 'a -> bytes -> int -> int val read_mmap : backend_mmap -> 'a -> bytes -> int -> int val read : t -> bytes -> int -> int -val write_fd : backend_fd -> 'a -> bytes -> int -> int +val write_fd : backend_fd -> 'a -> string -> int -> int val write_mmap : backend_mmap -> 'a -> string -> int -> int val write : t -> string -> int -> int val output : t -> bool diff --git a/tools/ocaml/libs/xb/xs_ring.ml b/tools/ocaml/libs/xb/xs_ring.ml index 48e06f4cbf..db7f86bd27 100644 --- a/tools/ocaml/libs/xb/xs_ring.ml +++ b/tools/ocaml/libs/xb/xs_ring.ml @@ -24,12 +24,14 @@ module Server_features = Set.Make(struct let compare = compare end) -external read: Xenmmap.mmap_interface -> string -> int -> int = "ml_interface_read" -external write: Xenmmap.mmap_interface -> string -> int -> int = "ml_interface_write" +external read: Xenmmap.mmap_interface -> bytes -> int -> int = "ml_interface_read" +external write: Xenmmap.mmap_interface -> bytes -> int -> int = "ml_interface_write" -external _internal_set_server_features: Xenmmap.mmap_interface -> int -> unit = "ml_interface_set_server_features" "noalloc" -external _internal_get_server_features: Xenmmap.mmap_interface -> int = "ml_interface_get_server_features" "noalloc" +external _internal_set_server_features: Xenmmap.mmap_interface -> int -> unit = "ml_interface_set_server_features" [@@noalloc] +external _internal_get_server_features: Xenmmap.mmap_interface -> int = "ml_interface_get_server_features" [@@noalloc] +let write_substring mmap buff len = + write mmap (Bytes.unsafe_of_string buff) len let get_server_features mmap = (* NB only one feature currently defined above *) @@ -43,4 +45,4 @@ let set_server_features mmap set = let x = if set = Server_features.empty then 0 else 1 in _internal_set_server_features mmap x -external close: Xenmmap.mmap_interface -> unit = "ml_interface_close" "noalloc" +external close: Xenmmap.mmap_interface -> unit = "ml_interface_close" [@@noalloc] -- 2.17.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.11 0/2] xenstore: reduce use of unsafe conversions
When xenstore was updated to support safe-string, some unnecessary copies were introduced. A further patch reduced the copies at the price of many calls to unsafe conversions between bytes and strings. In the port we also did not notice that some C stubs were still incorrectly using ocaml strings as mutable payload. This set of patches updates the C stubs that use mutable payloads passed from ocaml, and reduces the amount of unsafe conversions where possible without further increasing the number of copies. This seems also to fix some unclear instabilities that appeared after the former patch introducing the unsafe conversion with some version of the ocaml compiler. Marcello Seri (2): ocaml/libs/xb: use bytes in place of strings for mutable buffers ocaml/xenstored: reduce use of unsafe conversions tools/ocaml/libs/xb/xb.ml| 12 +--- tools/ocaml/libs/xb/xb.mli | 2 +- tools/ocaml/libs/xb/xs_ring.ml | 12 +++- tools/ocaml/xenstored/logging.ml | 16 ++-- tools/ocaml/xenstored/stdext.ml | 2 +- tools/ocaml/xenstored/utils.ml | 9 - 6 files changed, 24 insertions(+), 29 deletions(-) -- 2.17.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.10-testing test] 123389: tolerable FAIL - PUSHED
flight 123389 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123389/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-xsm 6 xen-install fail in 123344 pass in 123389 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-saverestore.2 fail in 123344 pass in 123389 test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail in 123344 pass in 123389 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail in 123344 pass in 123389 test-arm64-arm64-libvirt-xsm 6 xen-install fail in 123344 pass in 123389 test-armhf-armhf-libvirt-xsm 6 xen-installfail pass in 123344 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass in 123344 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 123344 never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 123344 never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: xen 7b35e7807c9efba0f74e6663a7205bd97602c8d1 baseline version: xen
Re: [Xen-devel] [PATCH 05/13] xen/arm: Add command line option to control SSBD mitigation
Hi, On 30/05/18 21:10, Stefano Stabellini wrote: On Wed, 30 May 2018, Julien Grall wrote: On 05/29/2018 11:34 PM, Stefano Stabellini wrote: On Tue, 29 May 2018, Julien Grall wrote: On 25/05/18 21:51, Stefano Stabellini wrote: On Thu, 24 May 2018, Julien Grall wrote: On 23/05/18 23:34, Stefano Stabellini wrote: On Tue, 22 May 2018, Julien Grall I should have read the spec more carefully, thanks for the pointer. Sorry about that. Finally, these patches are starting to make sense :-) All right. I can see why ssbd_state and ssbd_callback_required are separate and their purpose. Aside from adding more info to the commit message, I'll make a couple of different suggestions: 1) Let's check if ssbd_state == ARM_SSBD_UNKNOWN || ssbd_state == ARM_SSBD_MITIGATED at the beginning of has_ssbd_mitigation and return early in that case. This will help clarify the intended behavior and mitigate broken firmware returning ARM_SMCCC_NOT_SUPPORTED only on some cpus. This is just optional, I am fine either way. A vendor not able to do a simple return "ARM_SMCCC_NOT_SUPPORTED" in their firmware are not worth to support it in Xen. Most likely, more important bits of that firmware would be broken. 2) Can we turn ssbd_callback_required from a this_cpu variable to a single cpu bitmask? It is not great to introduce a new per-cpu varible for just one bit. It would save space and make it easier to access from assembly as a bitmask as it would remove the need for the ldr_this_cpu macro. If I am wrong and the bitmask makes things more complicated rather than simpler, then keep the code as is and just mention it in the next version of the patch. I hope you are aware that this will only save 8 byte per-CPU. On most of embedded platform you will have less than 16 CPUs. So you would save at most 128 bytes (woah!). If you are that tight in memory, then there are better place to reduce the footprint. I am also not sure to understand the problem of having ldr_this_cpu around. The macro is simple and in any case, you would still require at least a load for the bitmask. Feel free to suggest an assembly version for the bitmask. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 123391: tolerable all pass - PUSHED
flight 123391 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/123391/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123189 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123189 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123189 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass version targeted for testing: libvirt 57d6df39bd7eb8166fee68f4b6da03c0cb0802bf baseline version: libvirt b9eb0145eb3879c63152227afc0be0a1f5b8514a Last test of basis 123189 2018-05-25 07:51:05 Z6 days Failing since123212 2018-05-26 09:44:19 Z5 days5 attempts Testing same since 123391 2018-05-30 04:19:07 Z1 days1 attempts People who touched revisions under test: Jiri Denemark John Ferlan Ján Tomko Michal Privoznik Peter Krempa Roland Schulz jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Re: [Xen-devel] [PATCH v2 00/10] Intel Processor Trace virtulization enabling
> >> -Original Message- > >> From: Julien Grall [mailto:julien.gr...@arm.com] > >> Sent: Wednesday, May 30, 2018 11:15 PM > >> To: Kang, Luwei ; xen-de...@lists.xen.org > >> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; > >> ian.jack...@eu.citrix.com; jbeul...@suse.com; konrad.w...@oracle.com; > >> sstabell...@kernel.org; t...@xen.org; wei.l...@citrix.com; Nakajima, > >> Jun ; Tian, Kevin > >> Subject: Re: [PATCH v2 00/10] Intel Processor Trace virtulization > >> enabling > >> > >> Hi, > >> > >> Can you please avoid CC everyone on each patch? You can use > >> scripts/get_maintainers.pl on each patch to see who is required to be CCed. > > > > OK, get it. I use script/get_maintainers.pl to get the people who need to > > be CC and indeed different patch may include different > peoples. If somebody just receive one patch of this patch set may feel a > little strange and don't understand the context. So I CC all > the peoples who is mentioned in this patch set. > > That's usually why I CC everyone on the cover letter. Then for each patch I > CC only the necessary person. > > This avoids maintainers to have to look for what they should review/ack. Get it. This is a good way to me. Thanks. Luwei Kang ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL
On 31/05/18 10:32, Juergen Gross wrote: > On 31/05/18 08:00, osstest service owner wrote: >> flight 123379 xen-unstable real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/123379/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 >> fail REGR. vs. 123323 > > AFAICS this seems to be the suspected Windows reboot again? Hmm, thinking more about it: xl save is done with the domU paused, so the guest rebooting concurrently is rather improbable. As this is an issue occurring sporadically not only during 4.11 development phase I don't think this should be a blocker. Thoughts? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/10] Intel Processor Trace virtulization enabling
Hi, On 31/05/18 00:29, Kang, Luwei wrote: -Original Message- From: Julien Grall [mailto:julien.gr...@arm.com] Sent: Wednesday, May 30, 2018 11:15 PM To: Kang, Luwei ; xen-de...@lists.xen.org Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; ian.jack...@eu.citrix.com; jbeul...@suse.com; konrad.w...@oracle.com; sstabell...@kernel.org; t...@xen.org; wei.l...@citrix.com; Nakajima, Jun ; Tian, Kevin Subject: Re: [PATCH v2 00/10] Intel Processor Trace virtulization enabling Hi, Can you please avoid CC everyone on each patch? You can use scripts/get_maintainers.pl on each patch to see who is required to be CCed. OK, get it. I use script/get_maintainers.pl to get the people who need to be CC and indeed different patch may include different peoples. If somebody just receive one patch of this patch set may feel a little strange and don't understand the context. So I CC all the peoples who is mentioned in this patch set. That's usually why I CC everyone on the cover letter. Then for each patch I CC only the necessary person. This avoids maintainers to have to look for what they should review/ack. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL
On 31/05/18 08:00, osstest service owner wrote: > flight 123379 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/123379/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 > fail REGR. vs. 123323 AFAICS this seems to be the suspected Windows reboot again? > test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. > 123323 Flaky hardware again? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 123382: tolerable FAIL - PUSHED
flight 123382 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123382/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux102b97d6241d938ac153193504a5936fc0be27ed baseline version: linux1dff08485b9e835d00bfb34a435bc6f07dadb6fd Last test of basis 123147 2018-05-24 13:30:16 Z6 days Testing same since 123201 2018-05-26 01:30:05 Z5 days5 attempts People who touched revisions under test: Akinobu Mita Al Viro Alan Stern Alexander Duyck Alexander Potapenko Alexandre Belloni Amritha Nambiar Andrew Morton Andrew Vasquez Andrzej Hajda Antoine Tenart Arnd Bergmann Arvind Yadav Asutosh Das Baoquan He Bart Van Assche Ben Hutchings
[Xen-devel] [PATCH] ALSA: xen-front: signdness bug in alsa_prepare()
"sndif_format" needs to be signed for the error handling to work.
Fixes: 1cee559351a7 ("ALSA: xen-front: Implement ALSA virtual sound driver")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front_alsa.c b/sound/xen/xen_snd_front_alsa.c
index 5041f83e98d2..43478f66954a 100644
--- a/sound/xen/xen_snd_front_alsa.c
+++ b/sound/xen/xen_snd_front_alsa.c
@@ -463,7 +463,7 @@ static int alsa_prepare(struct snd_pcm_substream *substream)
if (!stream->is_open) {
struct snd_pcm_runtime *runtime = substream->runtime;
- u8 sndif_format;
+ int sndif_format;
int ret;
sndif_format = to_sndif_format(runtime->format);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ALSA: xen-front: fix a loop timeout
On Thu, 31 May 2018 08:44:39 +0200,
Oleksandr Andrushchenko wrote:
>
> On 05/31/2018 09:25 AM, Dan Carpenter wrote:
> > We want the loop to exit when "to" is set to zero, but in the current
> > code it's set to -1. Also I tweaked the indenting so it doesn't look
> > like we're passing "--to" to xenbus_read_unsigned().
> >
> > Fixes: cc3196ae197c ("ALSA: xen-front: Introduce Xen para-virtualized sound
> > frontend driver")
> > Signed-off-by: Dan Carpenter
> >
> > diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
> > index c18973a9bc9b..b089b13b5160 100644
> > --- a/sound/xen/xen_snd_front.c
> > +++ b/sound/xen/xen_snd_front.c
> > @@ -334,7 +334,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
> > */
> > while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
> > XenbusStateUnknown) !=
> > XenbusStateInitWait) &&
> > -to--)
> > + --to)
> > msleep(10);
> > if (!to) {
> Thank you for your patch,
> Reviewed-by: Oleksandr Andrushchenko
Applied, thanks.
Takashi
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ALSA: xen-front: signdness bug in alsa_prepare()
On 05/31/2018 09:25 AM, Dan Carpenter wrote:
"sndif_format" needs to be signed for the error handling to work.
Fixes: 1cee559351a7 ("ALSA: xen-front: Implement ALSA virtual sound driver")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front_alsa.c b/sound/xen/xen_snd_front_alsa.c
index 5041f83e98d2..43478f66954a 100644
--- a/sound/xen/xen_snd_front_alsa.c
+++ b/sound/xen/xen_snd_front_alsa.c
@@ -463,7 +463,7 @@ static int alsa_prepare(struct snd_pcm_substream *substream)
if (!stream->is_open) {
struct snd_pcm_runtime *runtime = substream->runtime;
- u8 sndif_format;
+ int sndif_format;
int ret;
sndif_format = to_sndif_format(runtime->format);
Thank you for your patch,
please see
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/sound/xen?h=for-next=014cea591afac9b3dae61793446f83d5be634203
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ALSA: xen-front: fix a loop timeout
On 05/31/2018 09:25 AM, Dan Carpenter wrote:
We want the loop to exit when "to" is set to zero, but in the current
code it's set to -1. Also I tweaked the indenting so it doesn't look
like we're passing "--to" to xenbus_read_unsigned().
Fixes: cc3196ae197c ("ALSA: xen-front: Introduce Xen para-virtualized sound frontend
driver")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
index c18973a9bc9b..b089b13b5160 100644
--- a/sound/xen/xen_snd_front.c
+++ b/sound/xen/xen_snd_front.c
@@ -334,7 +334,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
*/
while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
XenbusStateUnknown) != XenbusStateInitWait)
&&
-to--)
+ --to)
msleep(10);
if (!to) {
Thank you for your patch,
Reviewed-by: Oleksandr Andrushchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] ALSA: xen-front: fix a loop timeout
We want the loop to exit when "to" is set to zero, but in the current
code it's set to -1. Also I tweaked the indenting so it doesn't look
like we're passing "--to" to xenbus_read_unsigned().
Fixes: cc3196ae197c ("ALSA: xen-front: Introduce Xen para-virtualized sound
frontend driver")
Signed-off-by: Dan Carpenter
diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
index c18973a9bc9b..b089b13b5160 100644
--- a/sound/xen/xen_snd_front.c
+++ b/sound/xen/xen_snd_front.c
@@ -334,7 +334,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
*/
while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
XenbusStateUnknown) !=
XenbusStateInitWait) &&
-to--)
+ --to)
msleep(10);
if (!to) {
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality xen/gntdev: Expose gntdev's dma-buf API for in-kernel use drivers/xen/Kconfig | 23 + drivers/xen/Makefile |1 + drivers/xen/balloon.c | 71 +-- drivers/xen/gntdev.c | 1025 - I think this calls for gntdev_dma.c. I only had a quick look over gntdev changes but they very much are concentrated in dma-specific routines. You essentially only share file_operations entry points with original gntdev code, right? -boris drivers/xen/grant-table.c | 176 +- drivers/xen/mem-reservation.c | 134 + include/uapi/xen/gntdev.h | 106 include/xen/grant_dev.h | 37 ++ include/xen/grant_table.h | 28 + include/xen/mem_reservation.h | 29 + 10 files changed, 1527 insertions(+), 103 deletions(-) create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/grant_dev.h create mode 100644 include/xen/mem_reservation.h ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 123379: regressions - FAIL
flight 123379 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/123379/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail REGR. vs. 123323 test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 123323 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123323 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123323 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123323 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123323 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123323 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123323 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 123323 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123323 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123323 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123323 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 06f542f8f2e446c01bd0edab51e9450af7f6e05b baseline version: xen fc5805daef091240cd5fc06634a8bcdb2f3bb843 Last test of basis 123323 2018-05-28 23:34:10 Z2 days Testing same since 123379 2018-05-29 21:42:20 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Lars Kurth Marek Marczykowski-Górecki Tim Deegan Wei Liu jobs: build-amd64-xsm pass
