[Xen-devel] [linux-next test] 111799: regressions - FAIL

flight 111799 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/111799/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 7 reboot fail REGR. vs. 111771

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-libvirt

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-libvirt testid guest-saverestore.2 Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux

[Xen-devel] [PATCH v14 09/23] x86: refactor psr: L3 CAT: set value: assemble features value array.

Only can one COS ID be used by one domain at one time. That means all enabled features' COS registers at this COS ID are valid for this domain at that time. When user updates a feature's value, we need make sure all other features' values are not affected. So, we firstly need gather an array

[Xen-devel] [PATCH v14 07/23] x86: refactor psr: L3 CAT: implement get value flow.

There is an interface in user space to show feature value of domains. This patch implements get value flow in hypervisor. It also changes domctl interface to make it more general. With this patch, 'psr-cat-show' can work for L3 CAT but not for L3 code/data which is implemented in CDP related

[Xen-devel] [ovmf baseline-only test] 71692: all pass

This run is configured for baseline tests only. flight 71692 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71692/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0df6c8c157af9510e21bff7bb8aa1f461d04707b baseline

[Xen-devel] [PATCH v14 02/23] x86: move cpuid_count_leaf from cpuid.c to processor.h.

This patch moves 'cpuid_count_leaf' from cpuid.c to processor.h to make it available to external codes. Signed-off-by: Yi Sun Acked-by: Jan Beulich --- v9: - create this patch alone to move 'cpuid_count_leaf'. (suggested by Wei Liu) v6:

[Xen-devel] [PATCH v14 23/23] docs: add L2 CAT description in docs.

This patch adds L2 CAT description in related documents. Signed-off-by: He Chen Signed-off-by: Yi Sun Acked-by: Wei Liu --- v13: - rebase the patch on latest code. --- docs/man/xl.pod.1.in | 27

[Xen-devel] [PATCH v14 16/23] x86: L2 CAT: implement CPU init flow.

This patch implements the CPU init flow for L2 CAT. Signed-off-by: Yi Sun --- v14: - remove the 'Notes' in commit message because a stub function is implemented to avoid the potential issue. (suggested by Jan Beulich) - put address of 'feat_l2_cat'

[Xen-devel] [PATCH v14 08/23] x86: refactor psr: L3 CAT: set value: implement framework.

As set value flow is the most complicated one in psr, it will be divided to some patches to make things clearer. This patch implements the set value framework to show a whole picture firstly. It also changes domctl interface to make it more general. To make the set value flow be general and can

[Xen-devel] [PATCH v14 17/23] x86: L2 CAT: implement get hw info flow.

This patch implements L2 CAT get HW info flow and interface in sysctl. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich --- v10: - modify macro name according to previous patch change. (suggested by Jan Beulich) - modify commit message.

[Xen-devel] [PATCH v14 20/23] tools: L2 CAT: support get HW info for L2 CAT.

This patch implements xl/xc changes to support get HW info for L2 CAT. 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT info. Example(on machine which only supports L2 CAT): Cache Monitoring Technology (CMT): Enabled : 0 Cache Allocation Technology (CAT): L2 Socket ID : 0

[Xen-devel] [PATCH v14 22/23] tools: L2 CAT: support set cbm for L2 CAT.

This patch implements the xl/xc changes to support set CBM for L2 CAT. The new level option is introduced to original CAT setting command in order to set CBM for specified level CAT. - 'xl psr-cat-set' is updated to set cache capacity bitmasks(CBM) for a domain according to input cache level.

[Xen-devel] [PATCH v14 05/23] x86: refactor psr: L3 CAT: implement Domain init/free and schedule flows.

This patch implements the Domain init/free and schedule flows. - When domain init, its psr resource should be allocated. - When domain free, its psr resource should be freed too. - When domain is scheduled, its COS ID on the socket should be set into ASSOC register to make corresponding COS MSR

[Xen-devel] [PATCH v14 06/23] x86: refactor psr: L3 CAT: implement get hw info flow.

This patch implements get HW info flow including L3 CAT callback function. It also changes sysctl interface to make it more general. With this patch, 'psr-hwinfo' can work for L3 CAT. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich --- v12: -

[Xen-devel] [PATCH v14 21/23] tools: L2 CAT: support show cbm for L2 CAT.

This patch implements changes in xl/xc changes to support showing CBM of L2 CAT. The new level option is introduced to original CAT showing command in order to show CBM for specified level CAT. - 'xl psr-cat-show' is updated to show CBM of a domain according to input cache level. Examples:

[Xen-devel] [PATCH v14 19/23] x86: L2 CAT: implement set value flow.

This patch implements L2 CAT set value related callback function and domctl interface. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich --- v11: - remove 'domctl->u.psr_cat_op.data' check because it has been moved into 'psr_set_val'.

[Xen-devel] [PATCH v14 01/23] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

This patch creates CAT and CDP feature document in doc/features/. It describes key points to implement L3 CAT/CDP and L2 CAT which is described in details in Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION FEATURES". Signed-off-by: Yi Sun

[Xen-devel] [PATCH v14 03/23] x86: refactor psr: remove L3 CAT/CDP codes.

The current cache allocation codes in psr.c do not consider future features addition and are not friendly to extend. To make psr.c be more flexible to add new features and fulfill the program principle, open for extension but closed for modification, we have to refactor the psr.c: 1. Analyze

[Xen-devel] [PATCH v14 04/23] x86: refactor psr: L3 CAT: implement main data structures, CPU init and free flows.

To construct an extendible framework, we need analyze PSR features and abstract the common things and feature specific things. Then, encapsulate them into different data structures. By analyzing PSR features, we can get below map. +--+--+--+ ->| Dom0 |

[Xen-devel] [PATCH v14 11/23] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

Continue from previous patch: 'x86: refactor psr: L3 CAT: set value: implement cos finding flow.' If fail to find a COS ID, we need pick a new COS ID for domain. Only COS ID that ref[COS_ID] is 1 or 0 can be picked to input a new set feature values. Signed-off-by: Yi Sun

[Xen-devel] [PATCH v14 00/23] Enable L2 Cache Allocation Technology & Refactor psr.c

Hi all, We plan to bring a new PSR (Platform Shared Resource) feature called Intel L2 Cache Allocation Technology (L2 CAT) to Xen. It has been enabled in Linux Kernel. Besides the L2 CAT implementaion, we refactor the psr.c to make it more flexible and easily to extend to add new features. We

[Xen-devel] [PATCH v14 13/23] x86: refactor psr: CDP: implement CPU init flow.

This patch implements the CPU init flow for CDP. The flow is almost same as L3 CAT. Signed-off-by: Yi Sun --- v14: - remove the 'Notes' in commit message because a stub function is implemented to avoid potential issue. (suggested by Jan Beulich) -

[Xen-devel] [PATCH v14 10/23] x86: refactor psr: L3 CAT: set value: implement cos finding flow.

Continue from patch: 'x86: refactor psr: L3 CAT: set value: assemble features value array' We can try to find if there is a COS ID on which all features' COS registers values are same as the array assembled before. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v14 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

Continue from previous patch: 'x86: refactor psr: L3 CAT: set value: implement cos id picking flow.' We have got the feature value and COS ID to set. Then, we write MSRs of the designated feature. Till now, set value process is completed. Signed-off-by: Yi Sun ---

[Xen-devel] [PATCH v14 15/23] x86: refactor psr: CDP: implement set value callback function.

This patch implements L3 CDP set value related callback function. With this patch, 'psr-cat-cbm-set' command can work for L3 CDP. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich --- v13: - remove 'strict' from 'psr_cbm_type_to_feat_type' because

[Xen-devel] [PATCH v14 18/23] x86: L2 CAT: implement get value flow.

This patch implements L2 CAT get value interface in domctl. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich --- v14: - rebase domctl.c on latest codes: bool_t is replace by bool. v11: - remove "get_val' assignment because it has been replaced

[Xen-devel] [PATCH v14 14/23] x86: refactor psr: CDP: implement get hw info flow.

This patch implements get HW info flow for CDP including L3 CDP callback function. The flow is almost same as L3 CAT. With this patch, 'psr-hwinfo' can work for L3 CDP. Signed-off-by: Yi Sun Reviewed-by: Jan Beulich --- v12: - remove input

[Xen-devel] [libvirt test] 111792: tolerable all pass - PUSHED

flight 111792 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111792/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 111755 test-armhf-armhf-libvirt-xsm 14

[Xen-devel] [PATCH 1/6] xen-blkfront: quiesce/unquiesce queue instead of start/stop queues

stopping queue may cause race and may not stop the queue really after the API returns, and we have improved quiescing interface and it really can block dispatching once it returns. So switch to quiesce/unquiece like what we did on other drivers (NVMe, NBD, mtip32xx, ...) The

[Xen-devel] [ovmf test] 111810: all pass - PUSHED

flight 111810 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111810/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0df6c8c157af9510e21bff7bb8aa1f461d04707b baseline version: ovmf

[Xen-devel] [qemu-mainline test] 111790: regressions - FAIL

flight 111790 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/111790/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 111765 Tests

Re: [Xen-devel] [PATCH] IOMMU/PCI: make a few functions static

On Fri, Jul 14, 2017 at 08:05:05AM -0600, Jan Beulich wrote: > Add forward declarations in order to not move things around. > > Signed-off-by: Jan Beulich Reviewed-by: Wei Liu ___ Xen-devel mailing list

[Xen-devel] [linux-3.18 test] 111793: regressions - FAIL

flight 111793 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111793/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 REGR. vs. 110441

[Xen-devel] Question about Xen on ARM

Hello, I would like to test xen on an ARM target with one linux (as dom0) and one android (as domU).My goal is to prototype a system with one critical application (on linux side) and one non critical gui application (on android side). If possible, I don't want to do porting job (driver

Re: [Xen-devel] Renesas R-Car Gen3 SoCs earlyprintk support.

Hello Julien, On 05.07.17 19:50, Julien Grall wrote: Yocto aside, I think updating the wiki pages don't take too long. It is just adding: * Adding a point of contact in https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results * Make sure Salvator-X webpage is accurate and

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

On Fri, Jul 14, 2017 at 10:01:54AM -0600, Jan Beulich wrote: > >>> On 14.07.17 at 17:33, wrote: > > On Thu, Jul 13, 2017 at 08:36:18AM -0600, Jan Beulich wrote: > >> >>> Roger Pau Monne 06/30/17 5:01 PM >>> > >> > +#define container_of(ptr, type,

Re: [Xen-devel] [PATCH v4 2/9] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

On Thu, Jul 13, 2017 at 02:15:26PM -0600, Jan Beulich wrote: > >>> Roger Pau Monne 06/30/17 5:02 PM >>> > > @@ -1041,6 +1043,24 @@ static int __init pvh_setup_acpi(struct domain *d, > > paddr_t start_info) > > return 0; > > } > > > > +int __init

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

>>> On 14.07.17 at 17:33, wrote: > On Thu, Jul 13, 2017 at 08:36:18AM -0600, Jan Beulich wrote: >> >>> Roger Pau Monne 06/30/17 5:01 PM >>> >> > +#define container_of(ptr, type, member) ({ \ >> > +typeof(((type

[Xen-devel] [linux-4.9 test] 111786: regressions - FAIL

flight 111786 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111786/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 111411

Re: [Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

>>> On 08.06.17 at 21:30, wrote: > Add limited support for parsing IORT table to initialize SMMU devices. > > Signed-off-by: Sameer Goel > --- > xen/arch/arm/setup.c| 3 + > xen/drivers/acpi/Makefile | 1 + >

Re: [Xen-devel] [RFC 5/6] ACPI: arm: Support for IORT

>>> On 08.06.17 at 21:30, wrote: > Verbatim files from Linux kernel. This is pretty odd - they won't even come close to compile in that shape. But if the ARM folks are happy with it to be done this way, so be it. > iort.c: commit ca78d3173cff:Merge tag 'arm64-upstream'

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

On Thu, Jul 13, 2017 at 08:36:18AM -0600, Jan Beulich wrote: > >>> Roger Pau Monne 06/30/17 5:01 PM >>> > > --- /dev/null > > +++ b/tools/tests/vpci/Makefile > > @@ -0,0 +1,40 @@ > > + > > +XEN_ROOT=$(CURDIR)/../../.. > > +include $(XEN_ROOT)/tools/Rules.mk > > + > > +TARGET

Re: [Xen-devel] [PATCH v7 01/17] rbtree: changes to align the code with Linux tree

>>> On 14.07.17 at 16:57, wrote: > The patch aligns the code of rbtree related files with Linux tree. > This will minimize the conflicts during any future porting from Linux tree. > > Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h > This includes

Re: [Xen-devel] [PATCH v4 6/9] xen/vpci: add handlers to map the BARs

>>> On 30.06.17 at 17:01, wrote: > Introduce a set of handlers that trap accesses to the PCI BARs and the command > register, in order to emulate BAR sizing and BAR relocation. I don't think "emulate" is the right term here - you really don't mean to change anything, you

[Xen-devel] [PATCH v7 01/17] rbtree: changes to align the code with Linux tree

The patch aligns the code of rbtree related files with Linux tree. This will minimize the conflicts during any future porting from Linux tree. Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h This includes addition of commented inline functions in rbtree.h, to have complete

Re: [Xen-devel] Dump FDT for Linux Guest from Xen

Thanks Julien From: Julien Grall Sent: Friday, July 14, 2017 4:20 PM To: Waseem, Amna; sstabell...@kernel.org; xen-devel@lists.xen.org Subject: Re: [Xen-devel] Dump FDT for Linux Guest from Xen On 07/13/2017 12:40 PM, Waseem, Amna

Re: [Xen-devel] Dump FDT for Linux Guest from Xen

On 07/13/2017 12:40 PM, Waseem, Amna wrote: Hello All, Hello, Is there a way to dump FDT prepared by Xen given to Linux Guest while booting Domain 0. I want to see flattened device tree created by Xen by remapping I/O and IRQs for Guest. Is there a simple API to dump the flattened

Re: [Xen-devel] [PATCH v1] xen/grant-table: log the lack of grants

On 07/13/2017 06:42 PM, Wengang wrote: Hi, Hello, Anyone can you please review this patch? Most of the developer community were at Xen Summit this week, so you may expect some delay in review. However, in general it is better to CC relevant maintainers of your code to raise

Re: [Xen-devel] [PATCH v6 01/17] rbtree: changes to align the coding conventions with Linux tree

>>> On 14.07.17 at 15:47, wrote: > The patch aligns the coding style of rbtree related files to Linux coding > conventions to have limited conflicts in future while porting from Linux > tree. > > Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h >

[Xen-devel] [PATCH] IOMMU/PCI: make a few functions static

Add forward declarations in order to not move things around. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -587,6 +587,10 @@ static void pci_enable_acs(struct pci_de pci_conf_write16(seg, bus, dev, func, pos +

[Xen-devel] [PATCH] AMD IOMMU: drop amd_iommu_setup_hwdom_device()

By moving its bridge special casing to amd_iommu_add_device(), we can pass the latter to setup_hwdom_pci_devices() and at once consistently handle bridges discovered at boot time as well as such reported by Dom0 later on. Signed-off-by: Jan Beulich ---

[Xen-devel] [PATCH v6 01/17] rbtree: changes to align the coding conventions with Linux tree

The patch aligns the coding style of rbtree related files to Linux coding conventions to have limited conflicts in future while porting from Linux tree. Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h rbtree.h file includes commented inline functions in order to have

[Xen-devel] [xen-unstable test] 111777: tolerable FAIL

flight 111777 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/111777/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111751 pass in 111777 test-armhf-armhf-xl-rtds 16

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

>>> On 14.07.17 at 14:51, wrote: > On Fri, 2017-07-14 at 06:28 -0600, Jan Beulich wrote: >> > >> > > >> > > > >> > > > On 14.07.17 at 10:26, wrote: >> > The patch aligns the coding style of rbtree related files to Linux >> > coding >> >

[Xen-devel] [xen-unstable-smoke test] 111804: tolerable trouble: broken/pass - PUSHED

flight 111804 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/111804/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

On Fri, 2017-07-14 at 06:28 -0600, Jan Beulich wrote: > > > > > > > > > > > > > On 14.07.17 at 10:26, wrote: > > The patch aligns the coding style of rbtree related files to Linux > > coding > > conventions to have limited conflicts in future while porting from > >

[Xen-devel] Ping: [PATCH 11/11] gnttab: drop useless locking

>>> On 21.06.17 at 11:38, wrote: > Holding any lock while accessing the maptrack entry fields is > pointless, as these entries are protected by their associated active > entry lock (which is being acquired later, before re-validating the > fields read without holding the lock).

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

>>> On 14.07.17 at 10:26, wrote: > The patch aligns the coding style of rbtree related files to Linux coding > conventions to have limited conflicts in future while porting from Linux > tree. > > This patch includes only the style changes. Certainly not: In the header

Re: [Xen-devel] [PATCH v4] x86/monitor: Notify monitor if an emulation fails.

>>> On 12.07.17 at 19:21, wrote: > --- > tools/libxc/include/xenctrl.h | 2 ++ > tools/libxc/xc_monitor.c | 14 ++ > xen/arch/x86/hvm/emulate.c| 5 - > xen/arch/x86/hvm/monitor.c| 18 ++ >

Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1

>>> On 10.07.17 at 18:56, wrote: > Hello Jan, Pasi, all > >>> I noticed that PCI passthrough for an LSI SAS HBA 9211 did not longer work > (at least under Windows) when using Xen 4.8.1. >>> I then bisected through various released versions and finally I narrowed it > down to

Re: [Xen-devel] [PATCH 15/15] xen: tools: expose EPC in ACPI table

>>> On 09.07.17 at 10:16, wrote: > --- a/tools/firmware/hvmloader/util.c > +++ b/tools/firmware/hvmloader/util.c > @@ -330,6 +330,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, > uint32_t *ecx, uint32_t *edx) > : "0" (idx) ); > } > > +void

Re: [Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.

>>> On 14.07.17 at 09:37, wrote: > On 13/07/17 07:42, Huang, Kai wrote: >> On 7/12/2017 10:56 PM, Andrew Cooper wrote: >>> On 09/07/17 10:10, Kai Huang wrote: +/* Subleaf 2. */ +uint32_t base_valid:1, :11, base_pfn_low:20; +

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

>>> On 13.07.17 at 09:50, wrote: > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd, > XEN_GUEST_HANDLE_PARAM(void) arg) > break; > } > > +case EVTCHNOP_send_imm: > +

[Xen-devel] [qemu-mainline baseline-only test] 71690: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71690 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71690/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win10-i386 17

Re: [Xen-devel] [PATCH v9 0/7] Add LMCE support

>>> On 12.07.17 at 04:04, wrote: > Changes in v9: > * Minor updates in patch 1 per Jan's comments. > * Collect Jan's R-b in patch 2. > > Haozhong Zhang (7): > [M ] x86/domctl: generalize the restore of vMCE parameters > [ R ] x86/vmce: emulate

Re: [Xen-devel] [PATCH v4 5/9] xen/pci: split code to size BARs from pci_add_device

>>> On 30.06.17 at 17:01, wrote: > So that it can be called from outside in order to get the size of regular PCI > BARs. This will be required in order to map the BARs from PCI devices into PVH > Dom0 p2m. > > Signed-off-by: Roger Pau Monné > > ---

Re: [Xen-devel] [PATCH v4 4/9] xen/mm: move modify_identity_mmio to global file and drop __init

>>> On 30.06.17 at 17:01, wrote: > --- a/xen/common/memory.c > +++ b/xen/common/memory.c > @@ -1465,6 +1465,46 @@ int prepare_ring_for_helper( > return 0; > } > > +#if defined(CONFIG_X86) || defined(CONFIG_HAS_PCI) Why both? X86 selects HAS_PCI, and such (reverse)

Re: [Xen-devel] [PATCH v4 3/9] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

>>> On 30.06.17 at 17:01, wrote: > So that hotplug (or MMCFG regions not present in the MCFG ACPI table) > can be added at run time by the hardware domain. I think the emphasis should be the other way around. I'm rather certain hotplug of bridges doesn't really work right

Re: [Xen-devel] [PATCH v4 01/17] rbtree: changes to inline coding conventions with Linux tree

>>> On 14.07.17 at 07:07, wrote: > On Tue, 2017-07-04 at 02:24 -0600, Jan Beulich wrote: >> > > > On 03.07.17 at 21:58, wrote: >> > The patch inlines the rbtree related files to Linux coding >> > conventions to have >> > limited conflicts in

[Xen-devel] [distros-debian-jessie test] 71691: tolerable trouble: blocked/broken/pass

flight 71691 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71691/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a build-arm64-pvops

[Xen-devel] [linux-linus test] 111771: regressions - FAIL

flight 111771 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/111771/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 110515

[Xen-devel] [PATCH v5 11/17] rbtree: coding style adjustments

From: Michel Lespinasse Set comment and indentation style to be consistent with linux coding style and the rest of the file, as suggested by Peter Zijlstra Signed-off-by: Michel Lespinasse Cc: Andrea Arcangeli Acked-by: David

[Xen-devel] [PATCH v5 15/17] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()

From: Michel Lespinasse An interesting observation for rb_erase() is that when a node has exactly one child, the node must be black and the child must be red. An interesting consequence is that removing such a node can be done by simply replacing it with its child and making

[Xen-devel] [PATCH v5 17/17] rbtree: fix typo in comment of rb_insert_color

From: Wei Yang In case 1, it passes down the BLACK color from G to p and u, and maintains the color of n. By doing so, it maintains the black height of the sub-tree. While in the comment, it marks the color of n to BLACK. This is a typo and not consistents with the

[Xen-devel] [PATCH v5 14/17] rbtree: place easiest case first in rb_erase()

From: Michel Lespinasse In rb_erase, move the easy case (node to erase has no more than 1 child) first. I feel the code reads easier that way. Signed-off-by: Michel Lespinasse Reviewed-by: Rik van Riel Cc: Peter Zijlstra

[Xen-devel] [PATCH v5 13/17] rbtree: add __rb_change_child() helper function

From: Michel Lespinasse Add __rb_change_child() as an inline helper function to replace code that would otherwise be duplicated 4 times in the source. No changes to binary size or speed. Signed-off-by: Michel Lespinasse Reviewed-by: Rik van Riel

[Xen-devel] [PATCH v5 08/17] rbtree: adjust node color in __rb_erase_color() only when necessary

From: Michel Lespinasse In __rb_erase_color(), we were always setting a node to black after exiting the main loop. And in one case, after fixing up the tree to satisfy all rbtree invariants, we were setting the current node to root just to guarantee a loop exit, at which

[Xen-devel] [PATCH v5 05/17] rbtree: break out of rb_insert_color loop after tree rotation

From: Michel Lespinasse It is a well known property of rbtrees that insertion never requires more than two tree rotations. In our implementation, after one loop iteration identified one or two necessary tree rotations, we would iterate and look for more. However at that

[Xen-devel] [PATCH v5 16/17] rbtree: low level optimizations in rb_erase()

From: Michel Lespinasse Various minor optimizations in rb_erase(): - Avoid multiple loading of node->__rb_parent_color when computing parent and color information (possibly not in close sequence, as there might be further branches in the algorithm) - In the 1-child subcase

[Xen-devel] [PATCH v5 02/17] rbtree: remove redundant if()-condition in rb_erase()

From: Wolfram Strepp Furthermore, notice that the initial checks: if (!node->rb_left) child = node->rb_right; else if (!node->rb_right) child = node->rb_left; else { ...

[Xen-devel] [PATCH v5 07/17] rbtree: low level optimizations in rb_insert_color()

From: Michel Lespinasse - Use the newly introduced rb_set_parent_color() function to flip the color of nodes whose parent is already known. - Optimize rb_parent() when the node is known to be red - there is no need to mask out the color in that case. - Flipping gparent's

[Xen-devel] [PATCH v5 04/17] rbtree: move some implementation details from rbtree.h to rbtree.c

From: Michel Lespinasse rbtree users must use the documented APIs to manipulate the tree structure. Low-level helpers to manipulate node colors and parenthood are not part of that API, so move them to lib/rbtree.c Signed-off-by: Michel Lespinasse Cc:

[Xen-devel] [PATCH v5 12/17] rbtree: optimize fetching of sibling node

From: Michel Lespinasse When looking to fetch a node's sibling, we went through a sequence of: - check if node is the parent's left child - if it is, then fetch the parent's right child This can be replaced with: - fetch the parent's right child as an assumed sibling - check

[Xen-devel] [PATCH v5 09/17] rbtree: optimize case selection logic in __rb_erase_color()

From: Michel Lespinasse In __rb_erase_color(), we have to select one of 3 cases depending on the color on the 'other' node children. If both children are black, we flip a few node colors and iterate. Otherwise, we do either one or two tree rotations, depending on the color

[Xen-devel] [PATCH v5 00/17] xen: common: rbtree: ported updates from Linux tree

Hi All, The patch imports the changes and updates of the rbtree implementaiton from Linux tree. But since, the only current implementation is with tmem.c, which am not much aware off much and therefore, was unable to test the changes thoroughly. Having said that, I do have plans of adding futher

[Xen-devel] [PATCH v5 10/17] rbtree: low level optimizations in __rb_erase_color()

From: Michel Lespinasse In __rb_erase_color(), we often already have pointers to the nodes being rotated and/or know what their colors must be, so we can generate more efficient code than the generic __rb_rotate_left() and __rb_rotate_right() functions. Also when the current

[Xen-devel] [PATCH v5 03/17] rbtree: empty nodes have no color

From: Michel Lespinasse Empty nodes have no color. We can make use of this property to simplify the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE macros. Also, we can get rid of the rb_init_node function which had been introduced by commit 88d19cf37952 ("timers: Add

[Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

The patch aligns the coding style of rbtree related files to Linux coding conventions to have limited conflicts in future while porting from Linux tree. This patch includes only the style changes. Linux commit till 4c60117811171d867d4f27f17ea07d7419d45dae for rbtree.c Linux commit till

[Xen-devel] [PATCH v5 06/17] rbtree: adjust root color in rb_insert_color() only when necessary

From: Michel Lespinasse The root node of an rbtree must always be black. However, rb_insert_color() only needs to maintain this invariant when it has been broken - that is, when it exits the loop due to the current (red) node being the root. In all other cases (exiting after

Re: [Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.

On 13/07/17 07:42, Huang, Kai wrote: On 7/12/2017 10:56 PM, Andrew Cooper wrote: On 09/07/17 10:10, Kai Huang wrote: Why do we need this hide_epc parameter? If we aren't providing any epc resource to the guest, the entire sgx union should be zero and the SGX feature bit should be hidden.

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan > Beulich > Sent: 13 July 2017 21:36 > To: Andrew Cooper > Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu > ;

[Xen-devel] [ovmf baseline-only test] 71689: all pass

This run is configured for baseline tests only. flight 71689 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71689/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e baseline