[Xen-devel] [GIT PULL] xen: fix for 4.10 rc4

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.10-rc4-tag It contains a fix for Xen running in nested virtualization environment. Thanks. Juergen drivers/xen/platform-pci.c | 71 ++

Re: [Xen-devel] [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

On 18/01/17 21:14, Boris Ostrovsky wrote: > On 01/16/2017 09:15 AM, Juergen Gross wrote: >> + >> +static uint32_t xs_request_enter(struct xb_req_data *req) >> +{ >> +uint32_t rq_id; >> + >> +req->type = req->msg.type; >> + >> +spin_lock(_state_lock); >> +for (;;) { >> +

[Xen-devel] [PATCH v2] tools/tests: add xenstore testing framework

Add tools/tests/xenstore for a framework to do tests of xenstore. The aim is to test for correctness and performance. Add a test program containing some tests meant to be run against any xenstore implementation (xenstored, oxenstored, xenstore-stubdom). It is using libxenstore for access to

Re: [Xen-devel] [PATCH v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

On 17-01-18 10:11:15, Dario Faggioli wrote: > On Wed, 2017-01-18 at 10:02 +0800, Yi Sun wrote: > > This patch creates L2 CAT feature document in doc/features/. > > It describes details of L2 CAT. > > > > Signed-off-by: Yi Sun > > --- > > > Hey, > > it is very very

[Xen-devel] [PATCH RESEND v5 20/24] x86: L2 CAT: implement set value flow.

This patch implements L2 CAT set value related callback functions and domctl interface. Signed-off-by: Yi Sun --- v5: - remove type check in callback function. - modify return value of callback functions because we do not need them to return number of

[Xen-devel] [PATCH RESEND v5 23/24] 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-cbm-set' is updated to set cache capacity bitmasks(CBM) for a domain according to input cache

[Xen-devel] [PATCH RESEND v5 14/24] x86: refactor psr: implement get hw info flow for CDP.

This patch implements get HW info flow for CDP including L3 CDP callback function. It also changes sysctl function to make it work for CDP. With this patch, 'psr-hwinfo' can work for L3 CDP. Signed-off-by: Yi Sun --- v5: - rename 'dat[]' to 'data[]' - remove

[Xen-devel] [PATCH RESEND v5 08/24] x86: refactor psr: 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 RESEND v5 22/24] 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 RESEND v5 18/24] x86: L2 CAT: implement get hw info flow.

This patch implements get HW info flow for L2 CAT including L2 CAT callback function. Signed-off-by: Yi Sun --- v5: - rename 'dat[]' to 'data[]' - remove type check in callback function. --- xen/arch/x86/psr.c | 16

[Xen-devel] [PATCH RESEND v5 16/24] x86: refactor psr: implement set value callback functions for CDP.

This patch implements L3 CDP set value related callback functions. With this patch, 'psr-cat-cbm-set' command can work for L3 CDP. Signed-off-by: Yi Sun --- v5: - remove type check in callback function. - modify return value of callback functions because we do

[Xen-devel] [PATCH RESEND v5 19/24] x86: L2 CAT: implement get value flow.

This patch implements L2 CAT get value callback function and interface in domctl. Signed-off-by: Yi Sun --- v5: - remove type check in callback function. --- xen/arch/x86/domctl.c | 7 +++ xen/arch/x86/psr.c | 12

[Xen-devel] [PATCH RESEND v5 15/24] x86: refactor psr: implement get value flow for CDP.

This patch implements L3 CDP get value callback function. With this patch, 'psr-cat-show' can work for L3 CDP. Signed-off-by: Yi Sun --- v5: - remove type check in callback function. --- xen/arch/x86/psr.c | 16 1 file changed, 16 insertions(+)

[Xen-devel] [PATCH RESEND v5 24/24] 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 --- docs/man/xl.pod.1.in | 25 ++--- docs/misc/xl-psr.markdown | 10 -- 2 files changed, 30 insertions(+), 5

[Xen-devel] [PATCH RESEND v5 21/24] 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 RESEND v5 13/24] x86: refactor psr: implement CPU init and free flow for CDP.

This patch implements the CPU init and free flow for CDP including L3 CDP initialization callback function. Signed-off-by: Yi Sun --- v5: - remove 'feat_l3_cdp' free in 'free_feature'. - Encapsulate cpuid registers into 'struct cpuid_leaf_regs'. - Print

[Xen-devel] [PATCH RESEND v5 02/24] 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 RESEND v5 17/24] x86: L2 CAT: implement CPU init and free flow.

This patch implements the CPU init and free flow for L2 CAT including L2 CAT initialization callback function. Signed-off-by: Yi Sun --- v5: - remove 'feat_l2_cat' free in 'free_feature'. - Encapsulate cpuid registers into 'struct cpuid_leaf_regs'. - Print

[Xen-devel] [PATCH RESEND v5 10/24] x86: refactor psr: set value: implement cos finding flow.

Continue with patch: 'x86: refactor psr: 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 --- v5: - modify commit message to

[Xen-devel] [PATCH RESEND v5 05/24] x86: refactor psr: implement Domain init/free and schedule flows.

This patch implements the Domain init/free and schedule flows. Signed-off-by: Yi Sun --- v5: - define macro 'PSR_ASSOC_REG_POS' to replace integer 32. - rename 'l3_cat_get_max_cos_max' to 'l3_cat_get_cos_max'. - modify variables names to make them better,

[Xen-devel] [PATCH RESEND v5 06/24] x86: refactor psr: 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 --- v5: - add function 'psr_cbm_type_to_feat_type' to

[Xen-devel] [PATCH RESEND v5 03/24] x86: refactor psr: implement main data structures.

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 RESEND v5 12/24] x86: refactor psr: set value: implement write msr flow.

Continue with previous patch: 'x86: refactor psr: set value: implement cos id picking flow.' We have got all features values and COS ID to set. Then, we write MSRs of all features except the setting value is same as original value. Till now, set value process is completed. Signed-off-by: Yi Sun

[Xen-devel] [PATCH RESEND v5 11/24] x86: refactor psr: set value: implement cos id picking flow.

Continue with previous patch: 'x86: refactor psr: 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 RESEND v5 04/24] x86: refactor psr: implement CPU init and free flow.

This patch implements the CPU init and free flow including L3 CAT initialization and feature list free. Signed-off-by: Yi Sun --- v5: - modify commit message beacuse of code changes. - add 'struct cpuid_leaf_regs' to save cpu registers value to reduce

[Xen-devel] [PATCH RESEND v5 07/24] x86: refactor psr: implement get value flow.

This patch implements get value flow including L3 CAT callback function. It also changes domctl interface to make it more general. With this patch, 'psr-cat-show' can work for L3 CAT. Signed-off-by: Yi Sun --- v5: - rename 'dat[]' to 'data[]' - modify

[Xen-devel] [PATCH RESEND v5 09/24] x86: refactor psr: 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 assemble an array

[Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

This patch creates L2 CAT feature document in doc/features/. It describes details of L2 CAT. Signed-off-by: Yi Sun --- docs/features/intel_psr_l2_cat.pandoc | 347 ++ 1 file changed, 347 insertions(+) create mode 100644

[Xen-devel] [PATCH RESEND v5 00/24] 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. Besides the L2 CAT implementaion, we refactor the psr.c to make it more flexible to add new features and fulfill the principle, open for extension but closed for

[Xen-devel] [PATCH v2 1/3] x86/mtrr: drop positive_have_wrcomb()

The only call to have_wrcomb() was always to the generic implementation. positive_have_wrcomb() was unused. Signed-off-by: Doug Goldstein Acked-by: Jan Beulich --- Retaining ACK from <57b480fd027800106...@prv-mh.provo.novell.com> --- ---

[Xen-devel] [PATCH v2 2/3] x86/mtrr: drop unused func prototypes and struct

These weren't used so drop them. Signed-off-by: Doug Goldstein Reviewed-by: Jan Beulich --- Retained R-b from <57b48184027800106...@prv-mh.provo.novell.com> --- xen/arch/x86/cpu/mtrr/mtrr.h | 15 --- 1 file changed, 15 deletions(-) diff

[Xen-devel] [PATCH v2 3/3] x86/mtrr: convert use_intel_if u32 to bool

This field is always only 1 currently but may allow 0 in the future so convert it to a bool to provide proper range checking by the compiler. Signed-off-by: Doug Goldstein --- xen/arch/x86/cpu/mtrr/generic.c | 2 +- xen/arch/x86/cpu/mtrr/mtrr.h| 4 ++-- 2 files changed, 3

[Xen-devel] [PATCH v2 0/3] x86/mtrr: basic cleanups

Retained the parts that were not objected to by plans to disable mtrrs on PVH containers. Doug Goldstein (3): x86/mtrr: drop positive_have_wrcomb() x86/mtrr: drop unused func prototypes and struct x86/mtrr: convert use_intel_if u32 to bool xen/arch/x86/cpu/mtrr/generic.c | 7 +--

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

Hi Julien, On 12/29/2016 07:34 PM, Julien Grall wrote: > Hi all, > > The document below is an early version of a design > proposal for PCI Passthrough in Xen. It aims to > describe from an high level perspective the interaction > with the different subsystems and how guest will be able > to

[Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai During an OOM scenario, request slots could not be created as skb allocation fails. So the netback cannot pass in packets and netfront wrongly assumes that there is no more work to be done and it disables polling. This causes Rx to stall. The

[Xen-devel] [ovmf baseline-only test] 68391: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68391 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68391/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i3863 host-install(3) broken

Re: [Xen-devel] [PATCH 6/6] x86/cpuid: Only recalculate the shared feature bits once

On 1/18/17 2:40 PM, Andrew Cooper wrote: > With accurate vendor information available, the shared bits can be sorted out > during recalculation, rather than at query time in the legacy cpuid path. > > This means that: > * Duplication can be dropped from the automatically generated cpuid data. >

Re: [Xen-devel] [PATCH 5/6] x86/cpuid: Handle the long vendor string in guest_cpuid()

On 1/18/17 2:40 PM, Andrew Cooper wrote: > Leaves 0x8002 through 0x8004 are plain ASCII text, and require no > specific recalculation. > > Signed-off-by: Andrew Cooper Reviewed-by: Doug Goldstein -- Doug Goldstein signature.asc

Re: [Xen-devel] [PATCH 4/6] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()

On 1/18/17 2:40 PM, Andrew Cooper wrote: > The calculations for p->extd.max_leaf are reworked to force a value of at > least 0x8000, and to take the domains chosen vendor into account when > clamping maximum value. > > The high short vendor information is clobbered or duplicated according to

Re: [Xen-devel] [PATCH 3/6] x86/cpuid: Handle leaf 0 in guest_cpuid()

On 1/18/17 2:40 PM, Andrew Cooper wrote: > Calculate a domains x86_vendor early in recalculate_cpuid_policy(); subsequent > patches need to make other recalculation decisions based on it. > > Signed-off-by: Andrew Cooper Reviewed-by: Doug Goldstein

Re: [Xen-devel] [PATCH 2/6] x86/cpuid: Remove BUG_ON() condition from guest_cpuid()

On 1/18/17 2:40 PM, Andrew Cooper wrote: > Include a min() against the appropriate ARRAY_SIZE(), and ASSERT() that > max_subleaf is within ARRAY_SIZE(). > > This is more robust to unexpected problems in a release build of Xen. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 1/6] x86/cpuid: Hide VT-x/SVM from HVM-based control domains

On 1/18/17 2:40 PM, Andrew Cooper wrote: > The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper > mask, but nothing thusfar has prevented the features being visible in thus far? Could be the difference between British English and American English. > HVM-based control

[Xen-devel] [PATCH v5 2/5] efi: build xen.gz with EFI code

From: Daniel Kiper Build xen.gz with EFI code. We need this to support multiboot2 protocol on EFI platforms. If we wish to load non-ELF file using multiboot (v1) or multiboot2 then it must contain "linear" (or "flat") representation of code and data. This is requirement

[Xen-devel] [PATCH v5 0/5] multiboot2 protocol support

This is a series based on v11 of Daniel Kiper's "x86: multiboot2 protocol support" series. It aims to collect up all the fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in code review and testing on actual hardware. I've had problems with the relocation portion of the

[Xen-devel] [PATCH v5 5/5] fix: add multiboot2 protocol support for EFI platforms

This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol support for EFI platforms'. - fix incorrect assembly (identified by Andrew Cooper) - fix issue where the trampoline size was left as 0 and the way the memory is allocated for the trampolines we would go to the end of an

[Xen-devel] [PATCH v5 3/5] efi: create new early memory allocator

From: Daniel Kiper There is a problem with place_string() which is used as early memory allocator. It gets memory chunks starting from start symbol and goes down. Sadly this does not work when Xen is loaded using multiboot2 protocol because then the start lives on 1 MiB

[Xen-devel] [PATCH v5 4/5] x86: add multiboot2 protocol support for EFI platforms

From: Daniel Kiper This way Xen can be loaded on EFI platforms using GRUB2 and other boot loaders which support multiboot2 protocol. Signed-off-by: Daniel Kiper Reviewed-by: Doug Goldstein Tested-by: Doug Goldstein

[Xen-devel] [PATCH v5 1/5] x86: add multiboot2 protocol support

From: Daniel Kiper Add multiboot2 protocol support. Alter min memory limit handling as we now may not find it from either multiboot (v1) or multiboot2. This way we are laying the foundation for EFI + GRUB2 + Xen development. Signed-off-by: Daniel Kiper

Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms

On 1/18/17 4:25 PM, Daniel Kiper wrote: > On Wed, Jan 18, 2017 at 07:52:44AM -0700, Jan Beulich wrote: >> >> ... the comment style here fixed (which could be done upon commit >> or when Daniel merges this back into his series). > > Hmmm... Why this patch and #0 was not CC-ed to me? > You say

[Xen-devel] [distros-debian-squeeze test] 68390: trouble: blocked/broken

flight 68390 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68390/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3 host-install(3) broken

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

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

[Xen-devel] [xen-4.6-testing test] 104251: tolerable FAIL - PUSHED

flight 104251 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104251/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 103795

[Xen-devel] [xen-unstable-smoke test] 104276: tolerable all pass - PUSHED

flight 104276 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104276/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

On Wed, Jan 18, 2017 at 11:10:32PM +0100, Dario Faggioli wrote: > Hey, > > I'm afraid I can't comment on nothing, as I'm not at all into go. > > But there's a thing that I've noticed while skipping the patch out of > curiosity... > > On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote: > >

[Xen-devel] [xen-unstable baseline-only test] 68389: tolerable trouble: blocked/broken

This run is configured for baseline tests only. flight 68389 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68389/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-xsm 3 host-install(3)

Re: [Xen-devel] [PATCH] kexec: followup to STATUS patch v3 already in staging

On Wed, Jan 18, 2017 at 03:47:26PM -0600, Eric DeVolder wrote: > This contains the two corrections pointed out by Jan Beulich > for the kexec STATUS call just introduced. > > Note: In kexec_status(), the use of test_bit() can also return > EPERM, so the return value from test_bit() must be checked

Re: [Xen-devel] [PATCH 2/2] kexec: ensure kexec_status() always returns 0 or 1

On Wed, Jan 18, 2017 at 03:47:28PM -0600, Eric DeVolder wrote: > The use of test_bit() can also return EPERM, so the > return value from test_bit() must be checked to > ensure that kexec_status() always returns 0, 1 or > -1, per the public header description. > > Signed-off-by: Eric DeVolder

Re: [Xen-devel] [PATCH 1/2] Put back blank line for readability purposes.

On Wed, Jan 18, 2017 at 03:47:27PM -0600, Eric DeVolder wrote: > This blank line was accidentally removed during > the insertion of the kexec_status() declarations. > > Signed-off-by: Eric DeVolder Reviewed-by: Daniel Kiper Daniel

Re: [Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote: > Create error type Errorxl for throwing proper xenlight > errors. > > Update Ctx functions to throw Errorxl errors. > > Signed-off-by: Ronald Rojas > --- >  tools/golang/xenlight/xenlight.go | 77 >

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

Hey, I'm afraid I can't comment on nothing, as I'm not at all into go. But there's a thing that I've noticed while skipping the patch out of curiosity... On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote: > diff --git a/tools/Makefile b/tools/Makefile > index 77e0723..fd49e7f 100644 > ---

[Xen-devel] [PATCH 1/2] Put back blank line for readability purposes.

This blank line was accidentally removed during the insertion of the kexec_status() declarations. Signed-off-by: Eric DeVolder --- xen/include/public/kexec.h | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/include/public/kexec.h b/xen/include/public/kexec.h

[Xen-devel] [PATCH 2/2] kexec: ensure kexec_status() always returns 0 or 1

The use of test_bit() can also return EPERM, so the return value from test_bit() must be checked to ensure that kexec_status() always returns 0, 1 or -1, per the public header description. Signed-off-by: Eric DeVolder --- xen/common/kexec.c | 2 +- 1 file changed, 1

[Xen-devel] [PATCH] kexec: followup to STATUS patch v3 already in staging

This contains the two corrections pointed out by Jan Beulich for the kexec STATUS call just introduced. Note: In kexec_status(), the use of test_bit() can also return EPERM, so the return value from test_bit() must be checked to ensure that kexec_status() always returns 0, 1 or -1, per the public

[Xen-devel] [xen-4.7-testing test] 104250: regressions - FAIL

flight 104250 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104250/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail REGR. vs. 103850 Regressions

Re: [Xen-devel] [PATCH] xen/arm: gic-v3: Make sure read from ICC_IAR1_EL1 is visible on the redistributor

On Wed, 18 Jan 2017, Julien Grall wrote: > >From the GICv3 spec (IHI069C) section 4.1.1: > "The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a > returned INTID are not guaranteed to be visible until after the execution > of a DSB". > > Because of the GIC is an external

Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms

On Wed, Jan 18, 2017 at 07:52:44AM -0700, Jan Beulich wrote: > >>> On 18.01.17 at 15:17, wrote: > > This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol > > support for EFI platforms'. > > > > - fix incorrect assembly (identified by Andrew Cooper) > > - fix

Re: [Xen-devel] Followup corrections to kexec STATUS patch v3

On Wed, Jan 18, 2017 at 12:01:06PM -0600, Eric DeVolder wrote: > This contains the two corrections pointed out by Jan Beulich > for the kexec STATUS call just introduced. > > Note: In kexec_status(), the use of test_bit() can also return > EPERM, so the return value from test_bit() must be checked

Re: [Xen-devel] [PATCH 1/2] xen/kbdif: update protocol documentation

On Wed, 18 Jan 2017, Oleksandr Andrushchenko wrote: > On 01/12/2017 08:36 AM, Oleksandr Andrushchenko wrote: > > On 01/12/2017 12:50 AM, Dario Faggioli wrote: > > > On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote: > > > > On 01/11/2017 07:35 PM, Dario Faggioli wrote: > > > > >

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/18/2017 12:10 PM, David Miller wrote: This v2 never made it into patchwork. I don't know why, so please resend it to netdev with the accumulated reviewed-by etc. tags added. Thanks. Sorry about that. Will resend as a separate thread right away. Thanks

Re: [Xen-devel] [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

On 01/16/2017 09:15 AM, Juergen Gross wrote: > + > +static uint32_t xs_request_enter(struct xb_req_data *req) > +{ > + uint32_t rq_id; > + > + req->type = req->msg.type; > + > + spin_lock(_state_lock); > + for (;;) { > + if (req->msg.tx_id != 0) > +

Re: [Xen-devel] [PATCH v2 0/2] xen-netback: fix memory leaks on XenBus disconnect

From: Igor Druzhinin Date: Tue, 17 Jan 2017 20:49:36 + > Just split the initial patch in two as proposed by Wei. > > Since the approach for locking netdev statistics is inconsistent (tends not > to have any locking at all) accross the kernel we'd better to rely on

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

This v2 never made it into patchwork. I don't know why, so please resend it to netdev with the accumulated reviewed-by etc. tags added. Thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai Date: Wed, 18 Jan 2017 09:02:17 -0800 > > On 01/15/2017 10:24 PM, Juergen Gross wrote: >> On 13/01/17 18:55, Remanan Pillai wrote: >>> From: Vineeth Remanan Pillai >>> >>> During an OOM scenario, request slots could not be

Re: [Xen-devel] [PATCH v4 4/5] x86: add multiboot2 protocol support for EFI platforms

On 1/18/17 2:51 PM, Andrew Cooper wrote: > On 18/01/17 14:17, Doug Goldstein wrote: >> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S >> index d423fd8..ac93df0 100644 >> --- a/xen/arch/x86/boot/head.S >> +++ b/xen/arch/x86/boot/head.S >> @@ -89,6 +89,13 @@

Re: [Xen-devel] [PATCH v13 3/3] iommu: add rmrr Xen command line option for extra rmrrs

On Thu, Jan 12, 2017 at 04:44:42AM -0700, Jan Beulich wrote: > >>> On 10.01.17 at 23:57, wrote: > > Changes in v13: > > - Implement feedback from Kevin Tian. > > > > https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03169.html > > > >

[Xen-devel] [PATCH RFC 6/8] tools/xenlight: Implement libxl_scheduler enumeration

Include both constants and a Stringification for libxl_scheduler. Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas --- tools/golang/xenlight/xenlight.go | 72 +++ 1 file changed, 72 insertions(+) diff

[Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

Create error type Errorxl for throwing proper xenlight errors. Update Ctx functions to throw Errorxl errors. Signed-off-by: Ronald Rojas --- tools/golang/xenlight/xenlight.go | 77 +-- 1 file changed, 73 insertions(+), 4 deletions(-)

[Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

Create a basic Makefile to build and install libxenlight Golang bindings. Also add a stub package which only opens libxl context. Include a global xenlight.Ctx variable which can be used as the default context by the entire program if desired. For now, return simple errors. Proper error handling

[Xen-devel] [PATCH RFC 5/8] golang/xenlight: Implement libxl_bitmap and helper operations

Implement Bitmap type, along with helper functions. The Bitmap type is implemented interllay in a way which makes it easy to copy into and out of the C libxl_bitmap type. Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas ---

[Xen-devel] [PATCH RFC 4/8] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

Add calls for the following host-related functionality: - libxl_domain_info - libxl_domain_unpause Include Golang version for the libxl_domain_info as DomainInfo. Signed-off-by: George Dunlap Signed-off-by: Ronald Rojas ---

Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms

On 18/01/17 14:17, Doug Goldstein wrote: > This should be squashed into the 4/4 patch 'x86: add multiboot2 protocol > support for EFI platforms'. > > - fix incorrect assembly (identified by Andrew Cooper) > - fix issue where the trampoline size was left as 0 and the > way the memory is allocated

Re: [Xen-devel] [PATCH v4 4/5] x86: add multiboot2 protocol support for EFI platforms

On 18/01/17 14:17, Doug Goldstein wrote: > diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S > index d423fd8..ac93df0 100644 > --- a/xen/arch/x86/boot/head.S > +++ b/xen/arch/x86/boot/head.S > @@ -89,6 +89,13 @@ multiboot2_header_start: > 0, /* Number of the

[Xen-devel] [PATCH 2/6] x86/cpuid: Remove BUG_ON() condition from guest_cpuid()

Include a min() against the appropriate ARRAY_SIZE(), and ASSERT() that max_subleaf is within ARRAY_SIZE(). This is more robust to unexpected problems in a release build of Xen. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

[Xen-devel] [PATCH 3/6] x86/cpuid: Handle leaf 0 in guest_cpuid()

Calculate a domains x86_vendor early in recalculate_cpuid_policy(); subsequent patches need to make other recalculation decisions based on it. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpuid.c| 13 -

[Xen-devel] [PATCH 1/6] x86/cpuid: Hide VT-x/SVM from HVM-based control domains

The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper mask, but nothing thusfar has prevented the features being visible in HVM-based control domains (where there is no toolstack decision to hide the features). As a side effect of calling nestedhvm_enabled() earlier during

[Xen-devel] [PATCH 5/6] x86/cpuid: Handle the long vendor string in guest_cpuid()

Leaves 0x8002 through 0x8004 are plain ASCII text, and require no specific recalculation. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpuid.c| 3 +++ xen/include/asm-x86/cpuid.h | 4 ++-- 2 files changed, 5

[Xen-devel] [PATCH 0/6] x86/cpuid: Handling of simple leaves in guest_cpuid()

The following series (with any luck) is sufficient to allow PVH-dom0's to function without any CPUID policy hackary during construction. Andrew Cooper (6): x86/cpuid: Hide VT-x/SVM from HVM-based control domains x86/cpuid: Remove BUG_ON() condition from guest_cpuid() x86/cpuid: Handle leaf

[Xen-devel] [PATCH 4/6] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()

The calculations for p->extd.max_leaf are reworked to force a value of at least 0x8000, and to take the domains chosen vendor into account when clamping maximum value. The high short vendor information is clobbered or duplicated according to the chosen vendor. Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH 1/2] xen/kbdif: update protocol documentation

On 01/12/2017 08:36 AM, Oleksandr Andrushchenko wrote: On 01/12/2017 12:50 AM, Dario Faggioli wrote: On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote: On 01/11/2017 07:35 PM, Dario Faggioli wrote: It's indeed a repetition, but a good one, IMO: it helps the reader, as she

[Xen-devel] [PATCH 6/6] x86/cpuid: Only recalculate the shared feature bits once

With accurate vendor information available, the shared bits can be sorted out during recalculation, rather than at query time in the legacy cpuid path. This means that: * Duplication can be dropped from the automatically generated cpuid data. * The toolstack need not worry about setting them

Re: [Xen-devel] PV audio drivers for Linux

On 01/18/2017 08:52 PM, Stefano Stabellini wrote: On Wed, 18 Jan 2017, Ughreja, Rakesh A wrote: -Original Message- From: Stefano Stabellini [mailto:sstabell...@kernel.org] Sent: Wednesday, January 18, 2017 5:41 AM To: Ughreja, Rakesh A Cc:

Re: [Xen-devel] [PATCH v4 3/8] dm_op: convert HVMOP_track_dirty_vram

On 01/17/2017 12:29 PM, Paul Durrant wrote: The handle type passed to the underlying shadow and hap functions is changed for compatibility with the new hypercall buffer. NOTE: This patch also modifies the type of the 'nr' parameter of xc_hvm_track_dirty_vram() from uint64_t to uint32_t.

Re: [Xen-devel] xennet_start_xmit assumptions

On Wed, Jan 18, 2017 at 10:31:32AM -0500, Sowmini Varadhan wrote: > As I was playing around with pf_packet, I accidentally wrote > a buggy application program that bzero'ed the msghdr, then set > up the msg_name, msg_namelen correctly, and then did a sendmsg > on the pf_packet/SOCK_RAW fd. > >

Re: [Xen-devel] [PATCH v2 2/2] swiotlb-xen: implement xen_swiotlb_get_sgtable callback

On Wed, 18 Jan 2017, Andrii Anisov wrote: > Stefano, > > About this piece: > > > > > - if (__generic_dma_ops(dev)->get_sgtable) > > + > > + if (__generic_dma_ops(dev)->get_sgtable) { > > + /* We can't handle foreign pages here. */ > > +#ifdef CONFIG_ARM > > +

Re: [Xen-devel] [PATCH v4 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

On 01/17/2017 12:29 PM, Paul Durrant wrote: NOTE: This patch also modifies the types of the 'vector', 'type' and 'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to uint8_t. In practice the values passed were always truncated to 8 bits. Suggested-by: Jan Beulich

Re: [Xen-devel] [PATCH v4 6/8] dm_op: convert HVMOP_set_mem_type

On 01/17/2017 12:29 PM, Paul Durrant wrote: This patch removes the need for handling HVMOP restarts, so that infrastructure is removed. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the value passed was

Re: [Xen-devel] [PATCH v4 5/8] dm_op: convert HVMOP_modified_memory

On 01/17/2017 12:29 PM, Paul Durrant wrote: This patch introduces code to handle DMOP continuations. NOTE: This patch also modifies the type of the 'nr' argument of xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the value passed was always truncated to 32 bits.

Re: [Xen-devel] [PATCH v4 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

On 01/17/2017 12:29 PM, Paul Durrant wrote: ... HVMOP_set_pci_link_route These HVMOPs were exposed to guests so their definitions need to be preserved for compatibility. This patch therefore updates __XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP defintions conditional on

Re: [Xen-devel] [PATCH v4 2/8] dm_op: convert HVMOP_*ioreq_server*

On 01/17/2017 12:29 PM, Paul Durrant wrote: The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are already in use by callers of the libxc interface. Suggested-by: Jan Beulich Signed-off-by: Paul Durrant Acked-by: Daniel De Graaf

Re: [Xen-devel] [PATCH v4 1/8] public / x86: Introduce __HYPERCALL_dm_op...

On 01/17/2017 12:29 PM, Paul Durrant wrote: ...as a set of hypercalls to be used by a device model. As stated in the new docs/designs/dm_op.markdown: "The aim of DMOP is to prevent a compromised device model from compromising domains other then the one it is associated with. (And is therefore

  1   2   3   >