Re: [Xen-devel] [PATCH 5/6] x86/vvmx: Fix handing of the MSR_BITMAP field with VMCS shadowing

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > Currently, the following sequence of actions: > > * VMPTRLD (creates a mapping, likely pointing at gfn 0 for an empty vmcs) > * VMWRITE CPU_BASED_VM_EXEC_CONTROL (completed by hardware) > *

Re: [Xen-devel] Pass through in Xen

Hi, I have read that “From a software standpoint, PCI and PCI Express devices are essentially the same. PCIe devices had the same configuration space, BARs, and (usually) support the same PCI INTx interrupts”. According to my understanding, PCI and PCIe are different kind of interfaces with

Re: [Xen-devel] [PATCH] xen:arm earlyprintk configuration for Hikey 960 boards

Hi Konrad, On 27/07/17 02:18, Konrad Rzeszutek Wilk wrote: On Wed, Jul 26, 2017 at 05:59:15PM +0100, Julien Grall wrote: Hi Konrad, On 26/07/17 17:54, Konrad Rzeszutek Wilk wrote: Introduce an earlyprintk configuration of Hikey 960 boards. ..snip.. Would it be possible to update the wiki

[Xen-devel] [linux-linus test] 112330: regressions - trouble: blocked/broken/fail/pass

flight 112330 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112330/ 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. 110515

Re: [Xen-devel] [PATCH v2 1/5] x86/vmx: add struct vmx_msr_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > This structure provides a convenient way of accessing contents of > VMX MSRs: every bit value is accessible by its name. Bit names match > existing Xen's definitions as close as possible. The

Re: [Xen-devel] [PATCH 3/6] x86/vmx: Introduce and use struct vmx_msr_bitmap

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > This avoids opencoding the bitmap bases in accessor functions. Introduce a > build_assertions() function to check the structure layout against the manual > definiton. In addition, drop some

Re: [Xen-devel] [PULL 3/3] xen-disk: add support for multi-page shared rings

On Tue, Jun 27, Stefano Stabellini wrote: > From: Paul Durrant > The blkif protocol has had provision for negotiation of multi-page shared > rings for some time now and many guest OS have support in their frontend > drivers. > +++ b/hw/block/xen_disk.c > +domids =

[Xen-devel] [PATCH 2/5] xen: ARM: suspend the tick (if in use) when going idle.

Since commit 964fae8ac ("cpuidle: suspend/resume scheduler tick timer during cpu idle state entry/exit"), if a scheduler has a periodic tick timer, we stop it when going idle. This, however, is only true for x86. Make it true for ARM as well. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH 4/5] xen: RCU: don't let a CPU with a callback go idle.

If a CPU has a callback queued, it must be ready to invoke it, as soon as all the other CPUs involved in the grace period has gone through a quiescent state. But if we let such CPU go idle, we can't really tell when (if!) it will realize that it is actually time to invoke the callback. To solve

[Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

Xen is a tickless (micro-)kernel. This means that, when a CPU becomes idle, we stop all the activity on it, including any periodic tick or timer. When we imported RCU from Linux, Linux (x86) was a ticking kernel, i.e., there was a periodic timer tick always running, even on totally idle CPUs.

[Xen-devel] [PATCH 1/5] xen: in do_softirq() sample smp_processor_id() once and for all.

In fact, right now, we read it at every iteration of the loop. The reason it's done like this is how context switch was handled on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]). However: 1) we don't have IA64 any longer, and all the achitectures that we do support, are ok

[Xen-devel] [PATCH 5/5] xen: RCU: avoid busy waiting until the end of grace period.

Instead of having the CPU where a callback is queued, busy looping on rcu_pending(), use a timer. In fact, we let the CPU go idla,e but we program a timer that will periodically wake it up, for checking whether the grace period has actually ended. It is kind of similar to introducing a periodic

Re: [Xen-devel] [PATCH v2 2/5] x86/vmx: add raw_vmx_msr_policy

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > Add calculate_vmx_raw_policy() which fills the raw_vmx_msr_policy > object (the actual contents of H/W VMX MSRs) on the boot CPU. On > secondary CPUs, this function checks that contents of VMX MSRs

Re: [Xen-devel] [PATCH net] xen-netback: correctly schedule rate-limited queues

Op 2017-06-22 17:16, schreef David Miller: From: Wei Liu Date: Wed, 21 Jun 2017 10:21:22 +0100 Add a flag to indicate if a queue is rate-limited. Test the flag in NAPI poll handler and avoid rescheduling the queue if true, otherwise we risk locking up the host. The

Re: [Xen-devel] [PATCH 3/6] x86/vmx: Introduce and use struct vmx_msr_bitmap

> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of > Andrew Cooper > > On 27/07/2017 07:02, Tian, Kevin wrote: > >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > >> Sent: Wednesday, July 19, 2017 7:58 PM > >> > >> This avoids opencoding the bitmap bases in accessor

Re: [Xen-devel] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

On 27/07/17 10:24, Andrii Anisov wrote: Hello Julien, Hi, On 26.07.17 20:06, Julien Grall wrote: If you use the memory allocator for those reserved region, then they should be accounted in the domain memory. If not, then they are entirely separated and then no need to account them. Just add

Re: [Xen-devel] [PATCH 4/6] x86/vvmx: Switch nested MSR intercept handling to use struct vmx_msr_bitmap

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > Rename vmx_check_msr_bitmap() to vmx_msr_is_intercepted() in order to > more > clearly identify what the boolean return value means. Change the int > access_type to bool is_write. > > The NULL

Re: [Xen-devel] [PATCH v2 0/5] VMX MSRs policy for Nested Virt: part 1

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > The end goal of having VMX MSRs policy is to be able to manage > L1 VMX features. This patch series is the first part of this work. > There is no functional change to what L1 sees in VMX MSRs at this

Re: [Xen-devel] [PATCH 6/6] x86/vvmx: Fix auditing of MSR_BITMAP parameter

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Wednesday, July 19, 2017 7:58 PM > > The MSR_BITMAP field is required to be page aligned. Also switch gpa to be > a > uint64_t, as the MSR_BITMAP is strictly a 64bit VMCS field. > > Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH v2 3/5] x86/vmx: refactor vmx_init_vmcs_config()

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com] > Sent: Monday, July 24, 2017 9:48 PM > > 1. Remove RDMSRs of VMX MSRs since all values are already available in >raw_vmx_msr_policy. > 2. Replace bit operations involving VMX bitmasks with accessing VMX >features by name and using

[Xen-devel] [PATCH 0/5] xen: RCU: x86/ARM: Add support of rcu_idle_{enter, exit}

Hello everyone, It took some time, and, honestly, it was a bit of a nightmare, but I think I did manage to find a way to make our RCU implementation in a status where it does not only work "by chance" (as it does right now! :-O). A bit of background in this post:

Re: [Xen-devel] [PATCH 3/6] x86/vmx: Introduce and use struct vmx_msr_bitmap

On 27/07/2017 07:02, Tian, Kevin wrote: >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Wednesday, July 19, 2017 7:58 PM >> >> This avoids opencoding the bitmap bases in accessor functions. Introduce a >> build_assertions() function to check the structure layout against the

Re: [Xen-devel] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

Hello Julien, On 26.07.17 20:06, Julien Grall wrote: If you use the memory allocator for those reserved region, then they should be accounted in the domain memory. If not, then they are entirely separated and then no need to account them. Just add a separate memory node for it. I've got your

Re: [Xen-devel] Next Xen ARM community call - Wednesday 2nd August 2017

Works for EPAM as well On 07/27/2017 12:12 AM, Edgar E. Iglesias wrote: Hi, this time works for me too. I'd like to have a slot to introduce and discuss the work that Xilinx and Aggios are doing on Power management for Xen/Arm. Cheers, Edgar Sent from my phone On Jul 26, 2017 6:59 PM,

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

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

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

flight 112341 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112341/ 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] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

On 27/07/17 11:36, Andrii Anisov wrote: Dear Julien, On 27.07.17 12:55, Julien Grall wrote: It really depends on the security impact here. If the reserved memory is shared with other device, what would be the impact of a domain using the wrong memory attribute? I'm sorry, I did not get the

Re: [Xen-devel] race in vif-common.sh

On 07/03/2017 02:07 PM, Wei Liu wrote: > CC George (author of recent change) and Ian > > On Mon, Jul 03, 2017 at 01:30:09PM +0200, Andreas Kinzler wrote: >> Hello >> >> in /etc/xen/scripts/vif-common.sh there is a function handle_iptable. >> At its start there is a check for a working iptables

[Xen-devel] [PATCH] VT-d: don't panic/warn on iommu=no-igfx

When operating on an Intel graphics device, iommu_enable_translation() panicked (force_iommu==1) or warned (force_iommu==0) about the BIOS if is_igd_vt_enabled_quirk() returned 0. That's good if the actual BIOS problem has been detected. But since commit 1463411, returning 0 could also happen if

[Xen-devel] [libvirt test] 112336: regressions - trouble: blocked/broken/fail/pass

flight 112336 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112336/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 4 host-install(4)broken REGR. vs. 112276 build-arm64-xsm

Re: [Xen-devel] [PATCH v2] scripts/get_maintainers.pl: Don't blindly drop "THE REST" maintainers

On Wed, Jul 26, 2017 at 06:17:06PM +0100, Julien Grall wrote: > "THE REST" maintainers should always be CCed for any modification that > don't fall under the responsability of a specific component maintainer. > > However, the script get_maintainers.pl will remove "THE REST" > maintainers as soon

[Xen-devel] [PATCH] kexec: Provide a user friendly option for memory address limit

grub2 requires that the '<' character be escaped which is inconvienet for users, provide a more natural specifier. An example crashkernel argument may be crashkernel=256M,below=4G Signed-off-by: Simon Crowe --- docs/misc/kexec_and_kdump.txt | 8 +++-

[Xen-devel] [PATCH v2 1/6] xen/tools: credit2: soft-affinity awareness in runq_tickle()

Soft-affinity support is usually implemented by means of a two step "balancing loop", where: - during the first step, we consider soft-affinity (if the vcpu has one); - during the second (if we get to it), we consider hard-affinity. In runq_tickle(), we need to do that for checking whether we

[Xen-devel] Why xen-pirq chip use startup_irq() for .irq_enable?

Hi, Here is a device has xen-pirq-MSI interrupt. I found dom0 might lost interrupt during driver irq_disable/irq_enable. There is a pair of irq_disable/enable in driver. Here is the scenario, 1. irq_disable(dev_irq) -> disable_dynirq -> mask_evtchn(dev_irq channel) 2. dev interrupt raised by HW

Re: [Xen-devel] Possible bug on ARM with irq passthrough

Hello again, On Sat, 2017-07-08 at 09:25 +0200, Dario Faggioli wrote: > On Fri, 2017-07-07 at 17:19 +0100, Julien Grall wrote: > >  I would  > > recommend to stick on credit1 until this bug is fixed (I will mark > > it > > as  > > a blocker). > > > > Right. As said, it's on my priority list

Re: [Xen-devel] A document for Xen release management, v2

On Thu, Jul 27, 2017 at 11:30:11AM +0100, Julien Grall wrote: > > > On 25/07/17 14:25, Wei Liu wrote: > > Hi all > > Hi Wei, > > Sorry for the late reply. > > > ## Script to generate months update emails > > I have an updated script on which include jira ticket, version number: > Merged.

Re: [Xen-devel] [PATCH v3 3/3] docs: add pod variant of xl-numa-placement

On Wed, 2017-07-26 at 16:39 +0200, Olaf Hering wrote: > Convert source for xl-numa-placement.7 from markdown to pod. > This removes the buildtime requirement for pandoc, and subsequently > the > need for ghc, in the chain for BuildRequires of xen.rpm. > > Signed-off-by: Olaf Hering

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

flight 112334 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112334/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 4 host-install(4)broken REGR. vs. 111765 build-arm64

[Xen-devel] [PATCH v2 4/6] xen: credit2: kick away vcpus not running within their soft-affinity

If, during scheduling, we realize that the current vcpu is running outside of its own soft-affinity, it would be preferable to send it somewhere else. Of course, that may not be possible, and if we're too strict, we risk having vcpus sit in runqueues, even if there are idle pcpus (violating

[Xen-devel] [PATCH v2 0/6] Soft affinity for Credit2

Hello, Take 2 of soft-affinity for Credit2. Not much changed actually: - what was patch 1, it went in, so the series is shorter; :-) - in patch 5 ("xen: credit2: optimize runq_candidate() a little bit"), I changed things according to George's advice; - patch 2 ("xen: credit2: soft-affinity

[Xen-devel] [PATCH v2 2/6] xen: credit2: soft-affinity awareness in gat_fallback_cpu()

By, basically, moving all the logic of the function inside the usual two steps (soft-affinity step and hard-affinity step) loop. While there, add two performance counters (in cpu_pick and in get_fallback_cpu() itself), in order to be able to tell how frequently it happens that we need to look for

[Xen-devel] [PATCH v2 3/6] xen: credit2: soft-affinity awareness in csched2_cpu_pick()

We want to find the runqueue with the least average load, and to do that, we scan through all the runqueues. It is, therefore, enough that, during such scan: - we identify the runqueue with the least load, among the ones that have pcpus that are part of the soft affinity of the vcpu we're

[Xen-devel] [PATCH v2 5/6] xen: credit2: optimize runq_candidate() a little bit

By factoring into one (at the top) all the checks to see whether current is the idle vcpu, and mark it as unlikely(). In fact, if current is idle, all the logic for dealing with yielding, context switching rate limiting and soft-affinity, is just pure overhead, and we better rush checking the

[Xen-devel] [PATCH v2 6/6] xen: credit2: try to avoid tickling cpus subject to ratelimiting

With context switching ratelimiting enabled, the following pattern is quite common in a scheduling trace: 0.000845622 |||.x||| d32768v12 csched2:runq_insert d0v13, position 0 0.000845831 |||.x||| d32768v12 csched2:runq_tickle_new d0v13, processor = 12, credit = 10135529

Re: [Xen-devel] [PATCH v4 00/13] libxl: add PV display device driver interface

ping On 07/18/2017 05:25 PM, Oleksandr Grytsov wrote: From: Oleksandr Grytsov Changes since V3: * libxl__device_add renamed to libxl__device_add_async and reworked to match the former design; * libxl__device_add used for devices which don't require

Re: [Xen-devel] A document for Xen release management, v2

On 25/07/17 14:25, Wei Liu wrote: > Hi all Hi Wei, Sorry for the late reply. > ## Script to generate months update emails I have an updated script on which include jira ticket, version number: #!/bin/bash # Use ssmtp for simplicity # ./status-release.sh | formail -f -s /usr/sbin/ssmtp -bm

[Xen-devel] [xen-unstable test] 112332: regressions - trouble: blocked/broken/fail/pass

flight 112332 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112332/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 4 host-install(4)broken REGR. vs. 112286 build-arm64-xsm

Re: [Xen-devel] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

Dear Julien, On 27.07.17 12:55, Julien Grall wrote: It really depends on the security impact here. If the reserved memory is shared with other device, what would be the impact of a domain using the wrong memory attribute? I'm sorry, I did not get the point. Could you please provide an

Re: [Xen-devel] Reserved-memory node handling in XEN ( WAS Re: [ARM] Handling CMA pool device nodes in Dom0)

On 27.07.17 13:56, Julien Grall wrote: Let's rephrase it differently. Is the reserved memory always RAM or could it be other things? I think this have to be checked with the DT spec to have an answer. Well, if your region is cacheable it might be possible to have some data left in the cache

[Xen-devel] [PATCH V2 1/2] xen:arm64: Add SCIF UART support for earlyprintk

From: Iurii Konovalenko Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs. Signed-off-by: Iurii Konovalenko Signed-off-by: Iurii Mykhalskyi Signed-off-by: Andrii

Re: [Xen-devel] [PATCH v4 00/13] libxl: add PV display device driver interface

On Thu, Jul 27, 2017 at 02:30:33PM +0300, Oleksandr Andrushchenko wrote: > ping > It is on my list but I'm currently very busy with other urgent things. I will get to this in due time. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org

[Xen-devel] [PATCH V2 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

From: Andrii Anisov Introduce an earlyprintk configuration for R-Car Gen3 SoC based development boards, like: - Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X] - M3ULCB [http://elinux.org/R-Car/Boards/M3SK] - H3ULCB [http://elinux.org/R-Car/Boards/H3SK]

Re: [Xen-devel] [PATCH] kexec: Provide a user friendly option for memory address limit

>>> Simon Crowe 07/27/17 2:01 PM >>> >grub2 requires that the '<' character be escaped which is >inconvienet for users, provide a more natural specifier. > >An example crashkernel argument may be > >crashkernel=256M,below=4G > >Signed-off-by: Simon Crowe

Re: [Xen-devel] [PATCH] xen-pciback: Mark a PCIe device to be hidden on AER error

On 27/07/17 17:41, Boris Ostrovsky wrote: > On 07/27/2017 11:31 AM, Juergen Gross wrote: >> On 27/06/17 19:21, Venu Busireddy wrote: >>> This patch set is part of a set of patchs that together allow containment >>> of unrecoverable AER errors from PCIe devices assigned to guests in >>> passthrough

Re: [Xen-devel] Why xen-pirq chip use startup_irq() for .irq_enable?

(Adjusting addressees: David is no longer maintaining Xen code, Juergen is) On 07/27/2017 09:04 AM, shuo.a@intel.com wrote: > Hi, > Here is a device has xen-pirq-MSI interrupt. I found dom0 might lost > interrupt during driver irq_disable/irq_enable. > There is a pair of irq_disable/enable in

Re: [Xen-devel] [PATCH v2 09/13] xen/pvcalls: implement recvmsg

On 07/26/2017 08:08 PM, Stefano Stabellini wrote: > On Wed, 26 Jul 2017, Boris Ostrovsky wrote: + count++; + else + wait_event_interruptible(map->active.inflight_conn_req, +

Re: [Xen-devel] [PATCH 2/2] x86/svm: Drop unused SVM_REG_* definitions

On 07/26/2017 07:56 AM, Andrew Cooper wrote: > These are entirely unused, and are actually the general x86 register encoding, > rather than being SVM specific. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps

On Tue, Jul 25, 2017 at 07:00:47PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("[OSSTEST PATCH v13 19/24] TestSupport: Implement > target_subunit_cmd a subunit stream parser into substeps"): > > +# Read chunks of a part > > +while

Re: [Xen-devel] race in vif-common.sh

On Thu, 27 Jul 2017 12:55:14 +0200, George Dunlap wrote: For 4.9 we checked in a fix to this problem that would specifically attempt to use the -w option if it was available; see c/s 3d2010f9ff. Sorry, I think that this patch is just far to complicated. If you

Re: [Xen-devel] [PATCH 2/2] xen: dont fiddle with event channel masking in suspend/resume

On 07/17/2017 01:47 PM, Juergen Gross wrote: > Instead of fiddling with masking the event channels during suspend > and resume handling let do the irq subsystem do its job. It will do > the mask and unmask operations as needed. > > Signed-off-by: Juergen Gross Reviewed-by: Boris

[Xen-devel] [PATCH] xen: cleanup xen.h

The macros for testing domain types are more complicated then they need to. Simplify them. Signed-off-by: Juergen Gross --- include/xen/xen.h | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/include/xen/xen.h b/include/xen/xen.h index

Re: [Xen-devel] [PATCH 1/2] x86/svm: Alias the VMCB segment registers as an array

On 27/07/17 16:20, Boris Ostrovsky wrote: > On 07/26/2017 07:56 AM, Andrew Cooper wrote: >> This allows svm_{get,set}_segment_register() to access the user segments by >> array index, capitalising on x86_seg_* matches the hardware encoding. > This does read correctly to me, I think some sort of

Re: [Xen-devel] [PATCH] xen: cleanup xen.h

On 07/27/2017 11:11 AM, Juergen Gross wrote: > The macros for testing domain types are more complicated then they > need to. Simplify them. > > Signed-off-by: Juergen Gross > --- > include/xen/xen.h | 20 +--- > 1 file changed, 9 insertions(+), 11 deletions(-) >

Re: [Xen-devel] [PATCH] xen-pciback: Mark a PCIe device to be hidden on AER error

On 07/27/2017 11:31 AM, Juergen Gross wrote: > On 27/06/17 19:21, Venu Busireddy wrote: >> This patch set is part of a set of patchs that together allow containment >> of unrecoverable AER errors from PCIe devices assigned to guests in >> passthrough mode. The containment is achieved by killing

Re: [Xen-devel] [PATCH v2 05/13] xen/pvcalls: implement bind command

>> This all looks very similar to previous patches. Can it be factored out? > You are right that the pattern is the same for all commands: > - get a request > - fill the request > - possibly do something else > - wait > however each request is different, the struct and fields are different. >

Re: [Xen-devel] [OSSTEST PATCH v13 19/24] TestSupport: Implement target_subunit_cmd a subunit stream parser into substeps

On Wed, Jul 26, 2017 at 04:41:58PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("Re: [OSSTEST PATCH v13 19/24] TestSupport: Implement > target_subunit_cmd a subunit stream parser into substeps"): > > I think I start by looking at what kind of characters could be part of > > type and

Re: [Xen-devel] [PATCH] xen-pciback: Mark a PCIe device to be hidden on AER error

On 27/06/17 19:21, Venu Busireddy wrote: > This patch set is part of a set of patchs that together allow containment > of unrecoverable AER errors from PCIe devices assigned to guests in > passthrough mode. The containment is achieved by killing the guest and > hiding the device upon receiving the

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote: > Calculate entry PFN and flags just once. Convert the two successive > main if()-s to and if/elf-if chain. Restrict variable scope where > reasonable. Take the opportunity and also make the induction variable > unsigned. > >

[Xen-devel] No ARM64 testing in Xen Project Massachusetts Colo

Our remaining arm64 box, laxton1, seems to have died. The symptoms are similar to those of laxton0. I have asked our contractors to investigate on-site but I expect they will tell me it's dead. There are therefore currently no working arm64 test resources in the Xen Project test facility.

[Xen-devel] [PATCH] xen/arm: Fix comments coding style in assembler files

From: Andrii Anisov Signed-off-by: Andrii Anisov --- xen/arch/arm/arm32/debug-8250.inc | 12 +++-- xen/arch/arm/arm32/debug-exynos4210.inc | 12 +++-- xen/arch/arm/arm32/debug-pl011.inc | 18 +--- xen/arch/arm/arm32/debug-scif.inc

Re: [Xen-devel] [PATCH v2 02/13] xen/pvcalls: connect to the backend

>>> static int pvcalls_front_probe(struct xenbus_device *dev, >>> const struct xenbus_device_id *id) >>> { >>> + int ret = -EFAULT, evtchn, ref = -1, i; >>> + unsigned int max_page_order, function_calls, len; >>> + char *versions; >>> + grant_ref_t gref_head = 0;

[Xen-devel] [PATCH] x86/cpuid: Rename *_policy to *_cpuid_policy

In the future, there will be other policy objects, e.g. MSR. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpuid.c| 50 +++-- xen/arch/x86/hvm/hvm.c |

Re: [Xen-devel] [PATCH] x86/cpuid: Rename *_policy to *_cpuid_policy

On Thu, Jul 27, 2017 at 04:35:48PM +0100, Andrew Cooper wrote: > In the future, there will be other policy objects, e.g. MSR. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH 1/2] x86/svm: Alias the VMCB segment registers as an array

On 07/26/2017 07:56 AM, Andrew Cooper wrote: > This allows svm_{get,set}_segment_register() to access the user segments by > array index, capitalising on x86_seg_* matches the hardware encoding. This does read correctly to me, I think some sort of preposition is missing. "capitalising on

Re: [Xen-devel] [PATCH] xen: cleanup xen.h

On 27/07/17 17:37, Boris Ostrovsky wrote: > On 07/27/2017 11:11 AM, Juergen Gross wrote: >> The macros for testing domain types are more complicated then they >> need to. Simplify them. >> >> Signed-off-by: Juergen Gross >> --- >> include/xen/xen.h | 20 +--- >>

Re: [Xen-devel] [PATCH net] xen-netback: correctly schedule rate-limited queues

From: Jean-Louis Dupond Date: Thu, 27 Jul 2017 10:21:56 +0200 > Op 2017-06-22 17:16, schreef David Miller: >> From: Wei Liu >> Date: Wed, 21 Jun 2017 10:21:22 +0100 >> >>> Add a flag to indicate if a queue is rate-limited. Test the flag in >>> NAPI

Re: [Xen-devel] race in vif-common.sh

> On Jul 27, 2017, at 5:12 PM, Andreas Kinzler wrote: > > On Thu, 27 Jul 2017 12:55:14 +0200, George Dunlap > wrote: >> For 4.9 we checked in a fix to this problem that would specifically >> attempt to use the -w option if it was available; see c/s

Re: [Xen-devel] race in vif-common.sh

On Thu, 27 Jul 2017 18:49:47 +0200, George Dunlap wrote: Sorry, I think that this patch is just far to complicated. If you really want to keep the "iptables is working check" (lines 1-7 of function handle_iptable) then you should just move it inside the

Re: [Xen-devel] [PATCH v2 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich wrote: > This in turn calls for p2m_alloc_ptp() also being passed the numeric > level. > > Signed-off-by: Jan Beulich > --- > v2: New. > --- > Question is whether passing the level to p2m_alloc_ptp() is really all

[Xen-devel] [PATCH] Makefile: Fix uninstall target

Running "make uninstall" does not remove all installed files, a situation which might cause link related issues if xen is re-installed in a different location. In order to make uninstall correctly remove the files it is best the process should be done recursively by mirroring each "install" target

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

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

Re: [Xen-devel] Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

Jan Beulich writes ("Re: Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling"): > [Lars:] > >Ian: These are most likely software problems, most likely in Xen. > >ISSUE: nobody wants to debug Windows Heisenbugs > > Hmm, I think we believe to have

[Xen-devel] [PATCH RFC] x86/sysctl: Implement XEN_SYSCTL_get_cpuid_policy

Provide a SYSCTL for the toolstack to obtain complete system cpuid policy information. The CPUID information is serialised as an array of 6x 32bit integers, and a mechanism is provided to query the maximum number of entries Xen might write. For the XSM side of things, this subop is closely

[Xen-devel] [linux-linus test] 112338: regressions - trouble: blocked/broken/fail/pass

flight 112338 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112338/ 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. 110515

[Xen-devel] Xen 4.9 + kernel 4.13rc2 -- ballooning regression? reappearance of "Over-allocation for domain 1" errors

I've upgraded a Xen server's xen-4.9.0_08-517.2.x86_64 xen-libs-4.9.0_08-517.2.x86_64 kernel from 4.12x to 4.13x uname -rm 4.13.0-rc2-2.gb545b87-default x86_64 After upgrading, I see in my Dom0-attached serial console, a steady stream of, ...

Re: [Xen-devel] Notes Design Session: Making Releases Lessons Learned: Improving Our Release Process and Tooling

>>> Lars Kurth 07/18/17 2:18 PM >>> >x86 Heisenbugs in 4.9.0 >--- >- x86 migration Heisenbugs have caused us issues this release cycle: not >completely understood the issues and hard to debug > >Ian: These are most likely software problems, most

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

flight 112345 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112345/ 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

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

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

Re: [Xen-devel] Why xen-pirq chip use startup_irq() for .irq_enable?

On Thu 27.Jul'17 at 12:06:10 -0400, Boris Ostrovsky wrote: (Adjusting addressees: David is no longer maintaining Xen code, Juergen is) Thanks Boris. On 07/27/2017 09:04 AM, shuo.a@intel.com wrote: Hi, Here is a device has xen-pirq-MSI interrupt. I found dom0 might lost interrupt during

Re: [Xen-devel] [Qemu-devel] [PULL 3/3] xen-disk: add support for multi-page shared rings

On Thu, 27 Jul 2017, Olaf Hering wrote: > On Tue, Jun 27, Stefano Stabellini wrote: > > > From: Paul Durrant > > The blkif protocol has had provision for negotiation of multi-page shared > > rings for some time now and many guest OS have support in their frontend > >

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

This run is configured for baseline tests only. flight 71883 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71883/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1)

Re: [Xen-devel] preparations for 4.8.2

Quick info/update: > XSA-222: line 51 in the log shows a real difference: this is a known bug > in the tool where the diff file chunks are in a different order This is now fixed in the last version of the scripts and the script correctly handles this case Lars On 18/07/2017, 18:43, "Lars

Re: [Xen-devel] [PATCH v2 11/13] xen/pvcalls: implement release command

> +int pvcalls_front_release(struct socket *sock) > +{ > + struct pvcalls_bedata *bedata; > + struct sock_mapping *map; > + int req_id, notify; > + struct xen_pvcalls_request *req; > + > + if (!pvcalls_front_dev) > + return -EIO; > + bedata =

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

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

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

flight 112346 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112346/ 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] race in vif-common.sh

> On Jul 27, 2017, at 6:11 PM, Andreas Kinzler wrote: > > On Thu, 27 Jul 2017 18:49:47 +0200, George Dunlap > wrote: >>> Sorry, I think that this patch is just far to complicated. If you really >>> want to keep the "iptables is working check" (lines

[Xen-devel] (no subject)

Is it possible to use VFB for paravirtualised Guest? How to display Domain-U in physical monitor? I have added vfb in my Guest configuration and it returns the following error : Parsing config from /etc/xen/arch_domU_1.cfg libxl: error: libxl_dm.c:1233:libxl__spawn_local_dm: device model

[Xen-devel] [xen-unstable test] 112340: regressions - trouble: blocked/broken/fail/pass

flight 112340 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112340/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 4 host-install(4)broken REGR. vs. 112286 build-arm64-xsm

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

flight 112344 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112344/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 2 hosts-allocate broken REGR. vs. 111765 build-arm64-xsm