[Xen-devel] [xen-4.6-testing test] 101049: regressions - FAIL

flight 101049 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101049/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail REGR. vs. 101026

[Xen-devel] [PATCH v4 1/6] VMX: Statically assign two PI hooks

PI hooks: vmx_pi_switch_from() and vmx_pi_switch_to() are needed even when any previously assigned device is detached from the domain. Since 'SN' bit is also used to control the CPU side PI and we change the state of SN bit in these two functions, then evaluate this bit in

[Xen-devel] [PATCH v4 2/6] VMX: Properly handle pi when all the assigned devices are removed

This patch handles some concern cases when the last assigned device is removed from the domain. In this case we should carefully handle pi descriptor and the per-cpu blocking list, to make sure: - all the PI descriptor are in the right state when next time a devices is assigned to the domain

[Xen-devel] [PATCH v4 3/6] VMX: Cleanup PI per-cpu blocking list when vcpu is destroyed

We should remove the vCPU from the per-cpu blocking list if it is going to be destroyed. Signed-off-by: Feng Wu --- v4: - Call vmx_pi_list_cleanup() before vmx_destroy_vmcs() xen/arch/x86/hvm/vmx/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Xen-devel] [PATCH v4 5/6] VT-d: No need to set irq affinity for posted format IRTE

We don't set the affinity for posted format IRTE, since the destination of these interrupts is vCPU and the vCPU affinity is set during vCPU scheduling. Signed-off-by: Feng Wu --- v4: - Keep the construction of new_ire and only modify the hardware IRTE when it is not in posted

[Xen-devel] [PATCH v4 6/6] VMX: Fixup PI descritpor when cpu is offline

When cpu is offline, we need to move all the vcpus in its blocking list to another online cpu, this patch handles it. Signed-off-by: Feng Wu --- v4: - Remove the pointless check since we are in machine stop context and no other cpus go down in parallel.

[Xen-devel] [PATCH v4 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list

The current VT-d PI related code may operate incorrectly in the following scenarios: 1. When the last assigned device is dettached from the domain, all the PI related hooks are removed then, however, the vCPU can be blocked, switched to another pCPU, etc, all without the aware of PI. After the

[Xen-devel] [PATCH v4 4/6] VMX: Make sure PI is in proper state before install the hooks

We may hit the ASSERT() in vmx_vcpu_block in the current code, since vmx_vcpu_block() may get called before vmx_pi_switch_to() has been installed or executed. Here We use cmpxchg to update the NDST field, this can make sure we only update the NDST when vmx_pi_switch_to() has not been called. So

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 2016年09月20日 23:36, Jan Beulich wrote: >> The precondition of process_pending_softirq() working in the debug key >> > handler is that timer interrupt arrives on time and nmi_timer_fn() can >> > run to update nmi_timer_ticks before watchdog timeout. > Precondition? Process_pending_softirq() in

[Xen-devel] [xen-4.5-testing test] 101045: tolerable FAIL - PUSHED

flight 101045 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101045/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail like 100909

Re: [Xen-devel] [PATCH v6 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

> > This patch implemented parts of TODO left in commit id > > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush > > filtering in alloc_heap_pages()). It moved TLB-flush filtering out into > > populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very slow > > to create

[Xen-devel] [xen-unstable test] 101040: tolerable FAIL - PUSHED

flight 101040 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101040/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101008

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

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

Re: [Xen-devel] boot-wrapped xen image barfs with overlapped sections

I finally resolved this issue after hunting around. The clue comes from this page, https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_ARM_Guide: /chosen/module@1/reg should match bootwrapper model.lds. > Basically if I increase memory region for kernel, I should also update dts file on

[Xen-devel] [xen-4.6-testing baseline-only test] 67734: tolerable FAIL

This run is configured for baseline tests only. flight 67734 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67734/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-pvgrub 10 guest-start

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote: > > Paul, there's been no reply to > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html > > Jan > Jan: The refered to patch, commit a1b1572833, adds a check for vmfunc. I look a little time to look at the SDM

[Xen-devel] [xen-4.5-testing bisection] complete build-i386

branch xen-4.5-testing xenbranch xen-4.5-testing job build-i386 testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced:

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

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

[Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

From: Chris Patterson xs_watch() creates a thread to listen to xenstore events. Currently, the thread is created with the greater of 16K or PTHREAD_MIN_SIZE. There have been several bug reports and workarounds related to the issue where xs_watch() fails because its

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Tue, 20 Sep 2016, Julien Grall wrote: > Hi Stefano, > > On 20/09/2016 20:09, Stefano Stabellini wrote: > > On Tue, 20 Sep 2016, Julien Grall wrote: > > > Hi, > > > > > > On 20/09/2016 12:27, George Dunlap wrote: > > > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan > > >

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

flight 101056 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101056/ 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] [RFC 0/5] xen/arm: support big.little SoC

Hi Stefano, On 20/09/2016 20:09, Stefano Stabellini wrote: On Tue, 20 Sep 2016, Julien Grall wrote: Hi, On 20/09/2016 12:27, George Dunlap wrote: On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan wrote: On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote: On

[Xen-devel] [qemu-mainline test] 101032: trouble: broken/fail/pass

flight 101032 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/101032/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 3 host-install(3)broken REGR. vs.

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Tue, 20 Sep 2016, Julien Grall wrote: > Hi, > > On 20/09/2016 12:27, George Dunlap wrote: > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan wrote: > > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote: > > > > On Mon, 2016-09-19 at 17:01 -0700, Stefano

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

On 20/09/2016 18:01, "Ian Jackson" wrote: >Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision >making; some new roles and minor changes"): >> [proposal] > >Thanks. I've reviewed this and it looks generally good but I have >some specific comments. > >

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

On Tue, Sep 20, 2016 at 07:46:56AM -0600, Jan Beulich wrote: > >>> On 20.09.16 at 12:52, wrote: > > On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote: > >> >>> On 20.09.16 at 11:45, wrote: > >> > On Mon, Sep 19, 2016 at 09:17:50AM

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

On Tue, Sep 20, 2016 at 07:23:06AM -0600, Jan Beulich wrote: > >>> On 20.09.16 at 14:11, wrote: > > On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote: > >> >>> On 14.09.16 at 10:23, wrote: > >> > Additionally, my investigation has shown

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: > >>> On 19.09.16 at 15:56, wrote: > > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: [...] > >> So before taking this patch I'd really like to see proof that what gets > >> done currently does

[Xen-devel] Question about VPID during MOV-TO-CR3

Hi all, I'm trying to figure out the design decision regarding the handling of guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

On Tue, 2016-09-20 at 17:34 +0200, Julien Grall wrote: > On 20/09/2016 12:27, George Dunlap wrote: > > I think we definitely need to have Xen have some kind of idea the > > order between processors, so that the user doesn't need to figure > > out > > which class / pool is big and which pool is

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

flight 101047 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101047/ 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 v2 3/3] Significant changes to decision making; some new roles and minor changes

Lars Kurth writes ("[PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes"): > [proposal] Thanks. I've reviewed this and it looks generally good but I have some specific comments. Throughout you use "gage" where I think you should use "gauge". (AFAICT from

[Xen-devel] [xen-4.5-testing bisection] complete build-amd64

branch xen-4.5-testing xenbranch xen-4.5-testing job build-amd64 testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced:

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

On 09/20/2016 02:55 PM, Jan Beulich wrote: On 20.09.16 at 12:15, wrote: >> On 09/20/2016 08:13 AM, Jan Beulich wrote: >> On 19.09.16 at 19:54, wrote: On 09/19/2016 05:25 PM, Jan Beulich wrote: On 19.09.16 at 18:11,

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

flight 101029 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/101029/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 host-build-prep fail REGR. vs. 100999 Tests which did not

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

On Tue, Sep 20, 2016 at 9:39 AM, Jan Beulich wrote: On 20.09.16 at 17:14, wrote: >> On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote: >> On 20.09.16 at 16:56, wrote: On Tue, Sep 20,

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

flight 101026 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101026/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 101016 pass in 101026

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

>>> On 20.09.16 at 17:14, wrote: > On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote: > On 20.09.16 at 16:56, wrote: >>> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote: >>> On 19.09.16 at

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

>>> On 20.09.16 at 16:52, wrote: > On 9/19/2016 10:46 PM, Jan Beulich wrote: Well, without a clear understanding of why the issue occurs (for >> which I need to refer you back to the questionable stack dump) >> I'm hesitant to agree to this step, yet ... >>> >

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

Hi, On 20/09/2016 12:27, George Dunlap wrote: On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan wrote: On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli wrote: On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote: On Tue, 20 Sep 2016, Dario Faggioli wrote: I'd

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

On Mon, Sep 19, 2016 at 6:36 PM, Tian, Kevin wrote: >> From: Tamas K Lengyel >> Sent: Tuesday, September 20, 2016 12:40 AM >> >> >> --- a/xen/arch/x86/hvm/hvm.c >> >> +++ b/xen/arch/x86/hvm/hvm.c >> >> @@ -489,13 +489,16 @@ void hvm_do_resume(struct vcpu *v) >> >> >> >>

Re: [Xen-devel] New Outreachy Applicant

On Wed, Sep 14, 2016 at 7:35 AM, Ronald Rojas wrote: > Hi, I'm Ronald Rojas an undergraduate junior studying > computer science at New York Unversity. I would like > to apply fo the Xen projects Outreachy Program. After > looking through the available projects I think I would

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote: On 20.09.16 at 16:56, wrote: >> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote: >> On 19.09.16 at 20:27, wrote: On Mon, Sep 19,

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

>>> On 20.09.16 at 16:56, wrote: > On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote: > On 19.09.16 at 20:27, wrote: >>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote: >>> On 15.09.16 at

Re: [Xen-devel] [PATCH 13/24] libxc: improve error handling of xc Credit1 and Credit2 helpers

On Wed, Aug 17, 2016 at 07:19:04PM +0200, Dario Faggioli wrote: > In fact, libxc wrappers should, on error, set errno and > return -1. > > Signed-off-by: Dario Faggioli Acked-by: Wei Liu ___ Xen-devel

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

On 09/20/2016 05:56 PM, Tamas K Lengyel wrote: > On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote: > On 19.09.16 at 20:27, wrote: >>> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote: >>> On 15.09.16 at 18:51,

Re: [Xen-devel] [PATCH v4 0/4] libxl: add HVM USB passthrough capability

On Tue, Sep 20, 2016 at 04:18:06PM +0200, Juergen Gross wrote: > Add the capability to pass USB devices to HVM domains by using the > emulation of USB controllers of qemu. > > The user interface via xl is the same as for pvusb passthrough, only > the type of the usbctrl is different: instead of

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

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich wrote: On 19.09.16 at 20:27, wrote: >> On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich wrote: >> On 15.09.16 at 18:51, wrote: @@ -1793,7

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

On 09/20/2016 10:19 AM, Ian Jackson wrote: > Boris Ostrovsky writes ("Re: [PATCH v4 02/21] acpi: Prevent GPL-only code > from seeping into non-GPL binaries"): >> But yes, I can split dsdt.asl as well. Should we keep _S5 definition as >> GPL-only? > I think once we're going down this route there

Re: [Xen-devel] [PATCH v6 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

On Tue, Sep 20, 2016 at 10:31:04AM +0800, Dongli Zhang wrote: > This patch implemented parts of TODO left in commit id > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush > filtering in alloc_heap_pages()). It moved TLB-flush filtering out into > populate_physmap. Because of

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

On 9/19/2016 10:46 PM, Jan Beulich wrote: Well, without a clear understanding of why the issue occurs (for >> which I need to refer you back to the questionable stack dump) >> I'm hesitant to agree to this step, yet ... > > After some researches, I found do_invalid_op() on the stack dump is >

Re: [Xen-devel] [PATCH v4 3/4] libxl: add HVM usb passthrough support

On 20/09/16 15:18, Juergen Gross wrote: > Add HVM usb passthrough support to libxl by using qemu's capability > to emulate standard USB controllers. > > A USB controller is added via qmp command to the emulated hardware > when a usbctrl device of type DEVICEMODEL is requested. Depending on > the

Re: [Xen-devel] [PATCH v4 1/4] libxl: add function to remove usb controller xenstore entries

On Tue, Sep 20, 2016 at 04:18:07PM +0200, Juergen Gross wrote: > In case of failure when trying to add a new USB controller to a domain > libxl might leak xenstore entries. Add a function to remove them and > call this function in case of failure. > > Signed-off-by: Juergen Gross

Re: [Xen-devel] [PATCH 12/24] xen: libxc: allow to set the ratelimit value online

On Tue, Sep 20, 2016 at 03:43:57PM +0100, George Dunlap wrote: > On 17/08/16 18:18, Dario Faggioli wrote: > > The main purpose of the patch is to provide the xen-libxc > > plumbing necessary to be able to change the value of the > > ratelimit_us parameter online, for Credit2 (like it is > >

Re: [Xen-devel] [PATCH 12/24] xen: libxc: allow to set the ratelimit value online

On 17/08/16 18:18, Dario Faggioli wrote: > The main purpose of the patch is to provide the xen-libxc > plumbing necessary to be able to change the value of the > ratelimit_us parameter online, for Credit2 (like it is > already for Credit1). > > While there: > - mention in the Xen logs when rate

Re: [Xen-devel] [PATCH 11/24] tools: tracing: handle more scheduling related events.

On 17/08/16 18:18, Dario Faggioli wrote: > There are some scheduling related trace records that > are not being taken care of (and hence only dumped as > raw records). > > Some of them are being introduced in this series, while > other were just neglected by previous patches. > > Add support for

Re: [Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

On 17/08/16 18:18, Dario Faggioli wrote: > In both Credit2's trace records relative to checking > whether we want to preempt a vcpu (in runq_tickle()), > and to credits being burn, make it explicit on which > pcpu the vcpu being considered is running. > > Such information isn't currently

Re: [Xen-devel] [RFC PATCH 0/9] Introduce AMD SVM AVIC

On 09/19/2016 01:52 AM, Suravee Suthikulpanit wrote: > GITHUB > == > Latest git tree can be found at: > http://github.com/ssuthiku/xen.gitxen_avic_part1_v1 > > OVERVIEW > > This patch set is the first of the two-part patch series to introduce > the new AMD Advance Virtual

[Xen-devel] [PATCH v4 2/4] libxl: add basic support for devices without backend

With the planned support of HVM USB passthrough via the USB emulation capabilities of qemu libxl has to support guest devices which have no back- and frontend. Information about those devices will live in the libxl part of Xenstore only. Add some basic support to libxl to be able to cope with

Re: [Xen-devel] [PATCH v4 2/4] libxl: add basic support for devices without backend

On Tue, Sep 20, 2016 at 04:18:08PM +0200, Juergen Gross wrote: > With the planned support of HVM USB passthrough via the USB emulation > capabilities of qemu libxl has to support guest devices which have no > back- and frontend. Information about those devices will live in the > libxl part of

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote: > >>> On 20.09.16 at 14:35, wrote: > > On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich wrote: > > > >> >>> On 13.09.16 at 21:40, wrote: > >> > Allows for the

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

>>> On 08.09.16 at 18:21, wrote: > On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote: >> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and >> typo-ed the source file name of the EFI map file install command. > > I really need Fedora to

[Xen-devel] [PATCH] xen: switch to threaded irq in netback

Instead of open coding it use the threaded irq mechanism in xen-netback. Signed-off-by: Juergen Gross --- drivers/net/xen-netback/common.h| 4 +--- drivers/net/xen-netback/interface.c | 38 ++--- drivers/net/xen-netback/netback.c | 18

[Xen-devel] [PATCH v4 1/4] libxl: add function to remove usb controller xenstore entries

In case of failure when trying to add a new USB controller to a domain libxl might leak xenstore entries. Add a function to remove them and call this function in case of failure. Signed-off-by: Juergen Gross --- This patch might be a backport candidate to 4.7 (will have to

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

Boris Ostrovsky writes ("Re: [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries"): > But yes, I can split dsdt.asl as well. Should we keep _S5 definition as > GPL-only? I think once we're going down this route there is no benefit in trying to argue for individual

[Xen-devel] [PATCH v4 0/4] libxl: add HVM USB passthrough capability

Add the capability to pass USB devices to HVM domains by using the emulation of USB controllers of qemu. The user interface via xl is the same as for pvusb passthrough, only the type of the usbctrl is different: instead of "qusb" (qemu-based pvusb backend) or "vusb" (kernel-based pvusb backend)

[Xen-devel] [PATCH v4 4/4] docs: add HVM USB passthrough documentation

Update the man page regarding passthrough of USB devices to HVM domains via qemu USB emulation. Signed-off-by: Juergen Gross Acked-by: Wei Liu Acked-by: Ian Jackson --- V3: wording adjusted (Ian Jackson) ---

[Xen-devel] [PATCH v4 3/4] libxl: add HVM usb passthrough support

Add HVM usb passthrough support to libxl by using qemu's capability to emulate standard USB controllers. A USB controller is added via qmp command to the emulated hardware when a usbctrl device of type DEVICEMODEL is requested. Depending on the requested speed the appropriate hardware type is

Re: [Xen-devel] [PATCH 09/24] xen/tools: tracing: improve tracing of context switches.

On 17/08/16 18:18, Dario Faggioli wrote: > Right now, two out of the three events related to > context switch (that is TRC_SCHED_SWITCH_INFPREV and > TRC_SCHED_SWITCH_INFNEXT) only report the domain id, > and not the vcpu id. > > That's omitting a useful piece of information, and > even if we be

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

On 09/20/2016 06:14 AM, Ian Jackson wrote: > Boris Ostrovsky writes ("[PATCH v4 02/21] acpi: Prevent GPL-only code from > seeping into non-GPL binaries"): >> Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI >> support patch 3 of 4: ACPI _PRT table.")) has only been licensed

Re: [Xen-devel] [PATCH] tools: fix vif-route add|remove

On Wed, Sep 07, 2016 at 09:52:31AM -0600, Charles Arnold wrote: > From 2b4e942ad75f4a4546c417d8bd1116e3af368daf Mon Sep 17 00:00:00 2001 > From: Charles Arnold > Date: Wed, 7 Sep 2016 09:48:18 -0600 > Subject: [PATCH] tools: fix vif-route add|remove > > vif-route is called

Re: [Xen-devel] [PATCH v6 08/15] x86/efi: create new early memory allocator

>>> On 20.09.16 at 12:52, wrote: > On Tue, Sep 20, 2016 at 03:57:19AM -0600, Jan Beulich wrote: >> >>> On 20.09.16 at 11:45, wrote: >> > On Mon, Sep 19, 2016 at 09:17:50AM -0600, Jan Beulich wrote: >> >> >>> On 19.09.16 at 17:04,

Re: [Xen-devel] [PATCH v4 2/5] x86/time: implement tsc as clocksource

>>> On 20.09.16 at 12:15, wrote: > On 09/20/2016 08:13 AM, Jan Beulich wrote: > On 19.09.16 at 19:54, wrote: >>> On 09/19/2016 05:25 PM, Jan Beulich wrote: >>> On 19.09.16 at 18:11, wrote: > On

Re: [Xen-devel] [PATCH 08/24] xen: tracing: add trace records for schedule and rate-limiting.

On 17/08/16 18:18, Dario Faggioli wrote: > As far as {csched, csched2, rt}_schedule() are concerned, > an "empty" event, would already make it easier to read and > understand a trace. > > But while there, add a few useful information, like > if the cpu that is going through the scheduler has >

Re: [Xen-devel] [PATCH 06/24] xen: credit2: implement yield()

On 20/09/16 14:25, George Dunlap wrote: > On 17/08/16 18:18, Dario Faggioli wrote: >> When a vcpu explicitly yields it is usually giving >> us an advice of "let someone else run and come back >> to me in a bit." >> >> Credit2 isn't, so far, doing anything when a vcpu >> yields, which means an

[Xen-devel] [distros-debian-snapshot test] 67732: trouble: blocked/broken/pass

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

Re: [Xen-devel] [PATCH 07/24] xen: sched: don't rate limit context switches in case of yields

On 17/08/16 18:18, Dario Faggioli wrote: > In both Credit1 and Credit2, if a vcpu yields, let it... > well... yield! > > In fact, context switch rate limiting has been primarily > introduced to avoid too heavy context switch rate due to > interrupts, and, in general, asynchronous events. > > In

[Xen-devel] [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue

>From 97760602b5c94745e76ed78d23e8fdf9988d234e Mon Sep 17 00:00:00 2001 From: Quan Xu Date: Tue, 20 Sep 2016 21:12:54 +0800 Subject: [PATCH v2] x86/apicv: fix RTC periodic timer and apicv issue When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest with

Re: [Xen-devel] [PATCH v6 01/15] x86: properly calculate ELF end of image address

>>> On 20.09.16 at 13:43, wrote: > On Mon, Sep 19, 2016 at 08:52:02AM -0600, Jan Beulich wrote: >> >>> On 19.09.16 at 15:56, wrote: >> > On Mon, Sep 19, 2016 at 05:14:07AM -0600, Jan Beulich wrote: >> >> >>> On 16.09.16 at 22:43,

Re: [Xen-devel] [PATCH 06/24] xen: credit2: implement yield()

On 17/08/16 18:18, Dario Faggioli wrote: > When a vcpu explicitly yields it is usually giving > us an advice of "let someone else run and come back > to me in a bit." > > Credit2 isn't, so far, doing anything when a vcpu > yields, which means an yield is basically a NOP (well, > actually, it's

Re: [Xen-devel] [PATCH v3 3/4] libxl: add HVM usb passthrough support

On Tue, Sep 20, 2016 at 02:01:09PM +0200, Juergen Gross wrote: > Add HVM usb passthrough support to libxl by using qemu's capability > to emulate standard USB controllers. > > A USB controller is added via qmp command to the emulated hardware > when a usbctrl device of type DEVICEMODEL is

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

>>> On 20.09.16 at 14:11, wrote: > On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote: >> >>> On 14.09.16 at 10:23, wrote: >> > Additionally, my investigation has shown that there are no bound checks in >> > low memory allocation

[Xen-devel] [ vTPM ] ownership disappear

Hi everyone, when I create a vTPM instance and attached to it a VM, I use tpm-tools to take thw ownership of the vTPM. Then, if I destroy the vTPM and the VM, my expectation is that when I re-create the same vTPM attached to the same VM, the owership is already taken, but this is not the case: if

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

>>> On 20.09.16 at 14:35, wrote: > On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich wrote: > >> >>> On 13.09.16 at 21:40, wrote: >> > Allows for the conditional inclusion of VGA driver on the x86 platform >> > rather than having it always

Re: [Xen-devel] [PATCH] Fix issues introduced in 3a7f872a

On Tue, Sep 20, 2016 at 01:18:35PM +0100, Ian Jackson wrote: > Wei Liu writes ("[PATCH] Fix issues introduced in 3a7f872a"): > > 3a7f872a ("tools: lift BUILD_BUG_ON to a tools header file") was taken > > out from an rather old half finished branch by dropping unrelated > > changes. Unfortunately

[Xen-devel] [PATCH] VMX: don't bypass vmx_update_secondary_exec_control()

While putting together another patch modifying the secondary exec controls I noticed that vmx_vcpu_update_vmfunc_ve() does a raw VMWRITE instead of going through the designated function. I assume that is not how it should be. Signed-off-by: Jan Beulich ---

[Xen-devel] [xen-4.5-testing test] 101024: regressions - FAIL

flight 101024 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101024/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-buildfail REGR. vs. 100909 build-i386

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich wrote: > >>> On 13.09.16 at 21:40, wrote: > > Allows for the conditional inclusion of VGA driver on the x86 platform > > rather than having it always enabled. > > So I guess with all three of these patches an

Re: [Xen-devel] [PATCH] Fix issues introduced in 3a7f872a

Wei Liu writes ("[PATCH] Fix issues introduced in 3a7f872a"): > 3a7f872a ("tools: lift BUILD_BUG_ON to a tools header file") was taken > out from an rather old half finished branch by dropping unrelated > changes. Unfortunately two issues sneaked in. > > 1. Hvmloader should be standalone. Revert

[Xen-devel] [xen-4.7-testing test] 101022: tolerable FAIL - PUSHED

flight 101022 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/101022/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 101013 pass in 101022

Re: [Xen-devel] [PATCH v6 2/2] xen: move TLB-flush filtering out into populate_physmap during vm creation

On Tue, 2016-09-20 at 12:20 +0100, George Dunlap wrote: > On 20/09/16 03:31, Dongli Zhang wrote: > > > > This patch implemented parts of TODO left in commit id > > a902c12ee45fc9389eb8fe54eeddaf267a555c58 (More efficient TLB-flush > > filtering in alloc_heap_pages()). It moved TLB-flush filtering

Re: [Xen-devel] [PATCH v6 1/2] xen: replace tlbflush check and operation with inline functions

On Tue, 2016-09-20 at 12:19 +0100, George Dunlap wrote: > On 20/09/16 03:31, Dongli Zhang wrote: > > > > This patch cleaned up the code by replacing complicated tlbflush > > check and > > operation with inline functions. We should use those inline > > functions to > > avoid the complicated

Re: [Xen-devel] Fixes for low memory allocation machinery in early boot code

On Fri, Sep 16, 2016 at 06:15:10AM -0600, Jan Beulich wrote: > >>> On 14.09.16 at 10:23, wrote: > > Starting from the beginning it looks that there are "soft" limits enforced > > in BIOS early boot code looking for usable low memory region. Hight limit > > is set at 640

[Xen-devel] [PATCH v3 0/4] libxl: add HVM USB passthrough capability

Add the capability to pass USB devices to HVM domains by using the emulation of USB controllers of qemu. The user interface via xl is the same as for pvusb passthrough, only the type of the usbctrl is different: instead of "qusb" (qemu-based pvusb backend) or "vusb" (kernel-based pvusb backend)

[Xen-devel] [PATCH v3 3/4] libxl: add HVM usb passthrough support

Add HVM usb passthrough support to libxl by using qemu's capability to emulate standard USB controllers. A USB controller is added via qmp command to the emulated hardware when a usbctrl device of type DEVICEMODEL is requested. Depending on the requested speed the appropriate hardware type is

[Xen-devel] [PATCH v3 2/4] libxl: add basic support for devices without backend

With the planned support of HVM USB passthrough via the USB emulation capabilities of qemu libxl has to support guest devices which have no back- and frontend. Information about those devices will live in the libxl part of Xenstore only. Add some basic support to libxl to be able to cope with

[Xen-devel] [PATCH v3 1/4] libxl: add function to remove usb controller xenstore entries

In case of failure when trying to add a new USB controller to a domain libxl might leak xenstore entries. Add a function to remove them and call this function in case of failure. Signed-off-by: Juergen Gross Acked-by: Wei Liu --- This patch might be a

[Xen-devel] [PATCH v3 4/4] docs: add HVM USB passthrough documentation

Update the man page regarding passthrough of USB devices to HVM domains via qemu USB emulation. Signed-off-by: Juergen Gross Acked-by: Wei Liu Acked-by: Ian Jackson --- V3: wording adjusted (Ian Jackson) ---

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

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

  1   2   >