Re: [Xen-devel] AMD Radeon 7970 passthrough on XEN 4.4.3 with an AMD FX-8350/Gigabyte GA-970A-UD3 *HORROR*

Hello, On Sat, Sep 19, 2015 at 08:21:15PM +0300, NiX wrote: > After a lot of trial and error I got it working as a secondary > pass-through. Thanks mainly to bullshit examples around the net. None seem > to know nothing. > > I though of I am the idiot but I was wrong. > GPU passthru isn't very

Re: [Xen-devel] [PATCH for-4.6] xen/arm: vgic-v2: Map the GIC virtual CPU interface with the correct size

Hi Ian, On 21/09/15 12:54, Ian Campbell wrote: > On Fri, 2015-09-18 at 09:53 +0100, Ian Campbell wrote: >> On Thu, 2015-09-17 at 19:00 +0100, Julien Grall wrote: >>> On GICv2, the GIC virtual CPU interface is at minimum 8KB. Due some to >>> some necessary quirk for GIC using 64KB stride, we are

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

>>> On 16.09.15 at 21:47, wrote: > On 16/09/2015 09:47, Ross Lagerwall wrote: >> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for >> log-dirty"), the A and D bits of EPT paging entries are set >> unconditionally, regardless of whether PML is enabled or

Re: [Xen-devel] [PATCH v7 05/28] xen/arm: ITS: Port ITS driver to Xen

On 18/09/15 14:08, vijay.kil...@gmail.com wrote: > +static void its_lpi_free(struct its_device *dev) > +{ > +int lpi; > + > +spin_lock(_lock); > + > +for ( lpi = dev->event_map.lpi_base; > + lpi < (dev->event_map.lpi_base + dev->event_map.nr_lpis); > + lpi +=

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

> -Original Message- > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > Sent: Monday, September 21, 2015 9:32 PM > To: Wu, Feng; George Dunlap > Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew > Cooper; Jan Beulich > Subject: Re: [Xen-devel] [PATCH

Re: [Xen-devel] [PATCH] xen/x86: Record xsave features in c->x86_capabilities

On 21/09/15 15:00, Jan Beulich wrote: On 21.09.15 at 15:51, wrote: On 21/09/15 14:04, Jan Beulich wrote: On 17.09.15 at 13:40, wrote: Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the uncertainty with how this

[Xen-devel] [linux-mingo-tip-master test] 62148: regressions - FAIL

flight 62148 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/62148/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs.

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

>>> On 21.09.15 at 16:03, wrote: On 21.09.15 at 20:04, < jbeul...@suse.com > wrote: >> >>> On 21.09.15 at 11:46, wrote: >> >>> >>> On 21.09.15 at 16:51, < jbeul...@suse.com > wrote: >> >>- Anything else? >> > >> > >> > Just test the extreme case. The

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

At 20:47 +0100 on 16 Sep (1442436442), Andrew Cooper wrote: > On 16/09/2015 09:47, Ross Lagerwall wrote: > > Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for > > log-dirty"), the A and D bits of EPT paging entries are set > > unconditionally, regardless of whether PML is enabled or

Re: [Xen-devel] [PATCH v6 17/29] xen/x86: allow disabling the emulated PIC

>>> On 04.09.15 at 14:08, wrote: > @@ -425,6 +431,9 @@ void vpic_reset(struct domain *d) > > void vpic_init(struct domain *d) > { > +if ( !has_vpic(d) ) > +return; vpic_reset() above this function as well as functions further down in the source file aren't

Re: [Xen-devel] [PATCH v7 12/28] xen/arm: ITS: Plumbing hw_irq_controller for LPIs

Hi Vijay, Title: I would replace "Plumbing" by "Plumb" On 18/09/15 14:08, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Change callbacks gic_host_irq_type and gic_guest_irq_type > to gic_get_host_irq_type and gic_get_guest_irq_type > in

Re: [Xen-devel] [PATCH v2] xen: Improve x86's alloc_vcpu_guest_context()

On Mon, 2015-09-21 at 08:12 -0600, Jan Beulich wrote: > > > > On 17.09.15 at 18:52, wrote: > > This essentially reverts c/s 2037f2adb "x86: introduce > > alloc_vcpu_guest_context()", including the newer arm bits, but achieves > > the same end goal by using the newer

Re: [Xen-devel] [PATCH v7 13/28] xen/arm: Move vgic rank locking inside get_irq_priority

On 18/09/15 14:09, vijay.kil...@gmail.com wrote: > From: Vijaya Kumar K > > Move vgic rank locking inside get_irq_priority callback. > LPIs does not have vgic rank lock for reading LPI priority. > So make generic vgic code cleaner. The commit message is not

Re: [Xen-devel] [PATCH] xen/x86: Record xsave features in c->x86_capabilities

>>> On 21.09.15 at 15:51, wrote: > On 21/09/15 14:04, Jan Beulich wrote: > On 17.09.15 at 13:40, wrote: >>> Jan: I have opted for adding leaf 8 rather than reusing leaf 2, due to the >>> uncertainty with how this information is exposed in

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

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

Re: [Xen-devel] [PATCH v2] xen: Improve x86's alloc_vcpu_guest_context()

>>> On 17.09.15 at 18:52, wrote: > This essentially reverts c/s 2037f2adb "x86: introduce > alloc_vcpu_guest_context()", including the newer arm bits, but achieves > the same end goal by using the newer vmalloc() infrastructure. > > For both x86 and ARM,

Re: [Xen-devel] [PATCH] xen/x86: Record xsave features in c->x86_capabilities

>>> On 21.09.15 at 16:09, wrote: > On 21/09/15 15:00, Jan Beulich wrote: > On 21.09.15 at 15:51, wrote: >>> On 21/09/15 14:04, Jan Beulich wrote: >>> On 17.09.15 at 13:40, wrote: > +/* Mask out

Re: [Xen-devel] [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope with images containing only isolinux

Ian Jackson writes ("Re: [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope with images containing only isolinux"): > Ian Campbell writes ("Re: [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope > with images containing only isolinux"): > > Acked-by: Ian Campbell > >

[Xen-devel] DRAFT XSA 142 - libxl fails to honour readonly flag on disks with qemu-xen

* DRAFT DRAFT DRAFT * Xen Security Advisory XSA-142 libxl fails to honour readonly flag on disks with qemu-xen ISSUE DESCRIPTION = Callers of libxl can specify that a disk should be read-only to the guest. However, there is no code in libxl

Re: [Xen-devel] [PATCH v6 18/29] xen/x86: allow disabling the emulated pmu

On 09/21/2015 10:36 AM, Jan Beulich wrote: On 04.09.15 at 14:08, wrote: Hmm - this seems questionable to me: Isn't the vPMU an optional feature anyway? I.e. doesn't need separate handling here? Boris? It is optional system-wise, not per-guest, which is what I think

[Xen-devel] [PATCH 3/3] x86/p2m‑ept: adjust some types in ept_set_entry()

Use unsigned and bool_t as appropriate. Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/p2m-ept.c +++ b/xen/arch/x86/mm/p2m-ept.c @@ -662,12 +662,12 @@ ept_set_entry(struct p2m_domain *p2m, un { ept_entry_t *table, *ept_entry = NULL; unsigned long gfn_remainder =

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

>>> On 21.09.15 at 20:04, < jbeul...@suse.com > wrote: > >>> On 21.09.15 at 11:46, wrote: > >>> >>> On 21.09.15 at 16:51, < jbeul...@suse.com > wrote: > >>- Anything else? > > > > > > Just test the extreme case. The ATS specification mandates a timeout > > of 1 _minute_ for

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

George / Tim, Could you help me review these memory patches? Thanks! -Quan > -Original Message- > From: Xu, Quan > Sent: Wednesday, September 16, 2015 9:24 PM > To: andrew.coop...@citrix.com; Dong, Eddie; ian.campb...@citrix.com; > ian.jack...@eu.citrix.com; jbeul...@suse.com;

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote: > > > -Original Message- > > From: George Dunlap [mailto:george.dun...@citrix.com] > > You also need to check that local_events_need_delivery() will > > return > > "true" if you get an interrupt between that time and entering the > >

Re: [Xen-devel] [PATCH v6 18/29] xen/x86: allow disabling the emulated pmu

>>> On 04.09.15 at 14:08, wrote: Hmm - this seems questionable to me: Isn't the vPMU an optional feature anyway? I.e. doesn't need separate handling here? Boris? Jan > Signed-off-by: Roger Pau Monné > Acked-by: Andrew Cooper

Re: [Xen-devel] vTPM ownership problem

There are 2 error information: 1. The following is misleading, but correct. So ignore it. ERROR[VTPM]: LoadKey failure: Unrecognized uuid! 405ffc60-6b15-48e0-921a-d6645db0be03 ERROR[VTPM]: Failed to load key 2. This is maybe the problem: ERROR[VTPM]: LoadKey failure: Unrecognized uuid!

[Xen-devel] [seabios test] 62149: regressions - FAIL

flight 62149 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/62149/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 18 guest-start.2 fail REGR. vs. 62000 Regressions which

[Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU mapping updates

In the EPT case permission changes should also result in updates or TLB flushes. In the NPT case the old MFN does not depend on the new entry being valid (but solely on the old one), and the need to update or TLB-flush again also depends on permission changes. In the shadow mode case,

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote: > > > -Original Message- > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > > Note that, in case of preemptions, we are switching from a non-idle > > vcpu to another, non-idle, vcpu, so lazy context switching to the > > idle >

Re: [Xen-devel] [PATCH V2 0/2] Introspection optimization helpers

On 21/09/15 14:58, Razvan Cojocaru wrote: > Hello, Hi Razvan, > This doesn't have much to do with this series, but when running > scripts/get-maintainer.pl on my patches, I got "Stefano Stabellini > " for my first patch, and "Stefano > Stabellini

Re: [Xen-devel] [OSSTEST PATCH 21/26] ts-debian-hvm-install: Do not create EFI partition if EFI not in use

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > If we are booting our install ISO using a non-EFI executable, don't > try to provide an EFI for the installed system either. > > Signed-off-by: Ian Jackson FWIW the default recipes used by d-i use "$iflabel{ gpt

Re: [Xen-devel] [OSSTEST PATCH 22/26] ts-debian-hvm-install: Use /dev/sda for i386, not /dev/xvda

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > Empirically, the device shows up as /dev/sda. This is because the plain i386 kernel used by the installer does not support Xen (which requires PAE) and this affects even the options needed for PVHVM. amd64 on the other hand doesn't have this

Re: [Xen-devel] [OSSTEST PATCH 23/26] Timeouts: Introduce target_adjust_timeout

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > This function is now called for almost every timeout. > > Specifically, it is called in the cases in TestSupport where a guest- > or host-related timeout is passed from code which has a $ho or $gho, > to code which does not: all callers of

Re: [Xen-devel] [OSSTEST PATCH 24/26] Timeouts: Honour guest-related timeout-adjustment runvars

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > We look up a guest runvar GUEST_CONTEXT_timeoutfactor (according to > the usual rules for guest runvars). > > Here CONTEXT can currently be `general' or `install'. (`install' > applies when the guest is being installed.) If the runvar

Re: [Xen-devel] [OSSTEST PATCH 26/26] cri-common: Add a missing semicolon

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > This is not technically needed as bash interprets `a=1 b=2' as > settings of both a and b. But it's not idiomatic sh within osstest to > use this syntax. > > No functional change. > > Signed-off-by: Ian Jackson

Re: [Xen-devel] [OSSTEST PATCH 25/26] Debian i386 HVM tests: Increase installation timeout

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > The Debian i386 image boots a 32-bit non-PAE kernel which therefore > cannot have any PV drivers on our 64-bit hypervisors. This makes it a > bit slow: in my test on a machine under my desk it took 1400s out of > the allowed 2000s. > > With

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

On 09/21/2015 06:07 AM, Wu, Feng wrote: > > >> -Original Message- >> From: Wu, Feng >> Sent: Thursday, September 17, 2015 2:16 PM >> To: George Dunlap; Jan Beulich >> Cc: Tian, Kevin; Keir Fraser; Andrew Cooper; Dario Faggioli; >> xen-devel@lists.xen.org; Wu, Feng >> Subject: RE:

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

Thanks Jan. >> >>> On 21.09.15 at 16:51, < jbeul...@suse.com > wrote: >>> On 17.09.15 at 05:26, wrote: > Much more information: >If I run a service in this domain and tested this waitqueue case. > The domain is still working after 60s, but It prints out Call Trace with >

Re: [Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

Hi Peng, On 21/09/15 08:07, Peng Fan wrote: > To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional > check, but to ARM32, we need to use 'hsr.ec >> 30' to check. hsr.ec is encoded on 5 bits, therefore the shift you suggest is wrong. Maybe you wanted to use (hsr.ec >> 4)?

Re: [Xen-devel] [PATCH 1/2] xen: arm: traps: check hsr.ec for ARM32

Hi Julien, On Mon, Sep 21, 2015 at 10:47:23AM +0100, Julien Grall wrote: >Hi Peng, > >On 21/09/15 08:07, Peng Fan wrote: >> To ARM64, "if ( hsr.ec >= 0x10 ) return 1;" is ok for unconditional >> check, but to ARM32, we need to use 'hsr.ec >> 30' to check. > >hsr.ec is encoded on 5 bits, therefore

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

On 09/21/2015 06:09 AM, Wu, Feng wrote: > > >> -Original Message- >> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George >> Dunlap >> Sent: Friday, September 18, 2015 10:34 PM >> To: Dario Faggioli >> Cc: Jan Beulich; George Dunlap; Tian, Kevin; Keir Fraser; Andrew

[Xen-devel] [PATCH v12 0/1] toolstack-assisted approach to PVHVM guest kexec

This is the only not merged patch from the original 'toolstack-assisted approach to PVHVM guest kexec' series. Changes since v11: - Minor description change in xl.cfg.pod.5 [Wei Liu] - Goto-style error handling in do_domain_soft_reset() [Wei Liu] Original description of the series: The list of

[Xen-devel] [PATCH v12 1/1] (lib)xl: soft reset support

Use existing create/restore path to perform 'soft reset' for HVM domains. Tear everything down, e.g. destroy domain's device model, remove the domain from xenstore, save toolstack record and start over. Signed-off-by: Vitaly Kuznetsov --- Changes since v11: - Minor

Re: [Xen-devel] [PATCH OSSTEST] Correct html syntax error color=="#xxxxxx" => color="#xxxxxx"

Ian Campbell writes ("[PATCH OSSTEST] Correct html syntax error color=="#xx" => color="#xx""): > Strangely the effect of this (with iceweasel) was that everything was > cyan (#00fff0?) instead of the intended black or white. This will make some of the output black when previously it was

Re: [Xen-devel] [OSSTEST PATCH 15/26] cr*: Support xen-unstable-smoke

Ian Campbell writes ("Re: [OSSTEST PATCH 15/26] cr*: Support xen-unstable-smoke"): > On Mon, 2015-09-21 at 11:21 +0100, Ian Jackson wrote: > > if [ "x$branch" != "xxen-unstable" ]; then > > export REVISION_LINUX_OLD=disable > > fi > > That's the one which didn't need

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

>>> On 21.09.15 at 11:28, wrote: > On 09/21/2015 09:23 AM, Jan Beulich wrote: > On 16.09.15 at 18:56, wrote: >>> On Mon, Sep 7, 2015 at 1:54 PM, Jan Beulich wrote: >>> On 25.08.15 at 03:57,

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

> -Original Message- > From: George Dunlap [mailto:george.dun...@citrix.com] > Sent: Monday, September 21, 2015 5:54 PM > To: Wu, Feng; George Dunlap; Dario Faggioli > Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper; > xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH v7

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

flight 62146 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/62146/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 62042

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski wrote: > > In the interest of sanity, I want to drop the "native_", too Yes. I think the only reason it exists is to have that wrapper layer for PV. And that argument just goes away if you just make the non-inline helper

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On Mon, Sep 21, 2015 at 11:16:30AM -0700, Andy Lutomirski wrote: > In the interest of sanity, I want to drop the "native_", too, since > there appear to be few or no good use cases for native_read_msr as > such. I'm tempted to add new functions read_msr and write_msr that > forward to rdmsrl_safe

[Xen-devel] [qemu-upstream-4.5-testing test] 62151: regressions - FAIL

flight 62151 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62151/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60577

[Xen-devel] [qemu-upstream-4.3-testing baseline-only test] 37996: regressions - FAIL

This run is configured for baseline tests only. flight 37996 qemu-upstream-4.3-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/37996/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run:

Re: [Xen-devel] libxen-light

On Mon, 2015-09-21 at 11:56 +0530, kumara rathnavel wrote: > Hello, > > I do not find any proper documentation regarding API provided by the > Libxenlight. All I find is the documentation for the xl that in turn uses > Libxl Library. But I would like to use the library calls directly, I am > able

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* Andy Lutomirski wrote: > On Sep 20, 2015 5:15 PM, "Linus Torvalds" > wrote: > > > > On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote: > > > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > > >

Re: [Xen-devel] [PATCH 2/2] xen: Introduce VM_EVENT_FLAG_SET_EIP

>>> On 18.09.15 at 21:19, wrote: > On Wed, Sep 16, 2015 at 12:12 PM, Razvan Cojocaru > wrote: >> I have nothing in principle against having a SET_REGISTERS flag instead >> of a SET_EIP one, but I am unsure of how (and where) that would be best >>

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

On 09/21/2015 06:08 AM, Wu, Feng wrote: > > >> -Original Message- >> From: George Dunlap [mailto:george.dun...@citrix.com] >> Sent: Thursday, September 17, 2015 5:38 PM >> To: Dario Faggioli; Wu, Feng >> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew >>

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

On 09/21/2015 09:23 AM, Jan Beulich wrote: On 16.09.15 at 18:56, wrote: >> On Mon, Sep 7, 2015 at 1:54 PM, Jan Beulich wrote: >> On 25.08.15 at 03:57, wrote: --- a/xen/arch/x86/domain.c +++

Re: [Xen-devel] [OSSTEST PATCH 19/26] ts-debian-hvm-install: Cope with images containing only isolinux

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > debian-7.2.0-i386-CD-1.iso contains no grub, only isolinux. > > If the specified EFI grub file does not exist, fall back to isolinux. > This requires a -c option as well, according to > https://wiki.debian.org/DebianInstaller/Modify/CD >

Re: [Xen-devel] [OSSTEST PATCH 20/26] ts-debian-hvm-install: Set $gsuite after $gho

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > $gsuite was set from guest_var, but before $gho was set, leading to an > undefined value warning from Perl. > > This would ignore any guest-specific suite runvars. AFAICT these are > set by some of the jobs in make-distros-flight. I think

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

>>> On 16.09.15 at 18:56, wrote: > On Mon, Sep 7, 2015 at 1:54 PM, Jan Beulich wrote: > On 25.08.15 at 03:57, wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -1573,6 +1573,22 @@ static void

Re: [Xen-devel] [qemu-mainline bisection] complete test-armhf-armhf-xl-vhd

This looks to be the issue which Anthony investigated last week and for which the responsible patch has been reverted. I think this bisection just hadn't caught up with the fact that the issue is fixed yet. Ian. On Mon, 2015-09-21 at 05:36 +, osstest service owner wrote: > branch

Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

>>> On 17.09.15 at 05:26, wrote: > Much more information: >If I run a service in this domain and tested this waitqueue case. The > domain is still working after 60s, but It prints out Call Trace with $dmesg: > > [ 161.978599] BUG: soft lockup - CPU#0 stuck for 57s!

Re: [Xen-devel] [PATCH 2/2] xen: Introduce VM_EVENT_FLAG_SET_EIP

On 09/21/2015 11:53 AM, Jan Beulich wrote: On 18.09.15 at 21:19, wrote: >> On Wed, Sep 16, 2015 at 12:12 PM, Razvan Cojocaru >> wrote: >>> I have nothing in principle against having a SET_REGISTERS flag instead >>> of a SET_EIP one, but I am

Re: [Xen-devel] [OSSTEST PATCH 15/26] cr*: Support xen-unstable-smoke

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > Add this branch to select_xenbranch. This works like xen-unstable in > most respects. > > There are only two places in osstest where xenbranch `xen-unstable' is > treated specially and only one of them needs adjusting to match >

Re: [Xen-devel] [OSSTEST PATCH 18/26] ts-debian-hvm-install, etc.: Do not hardcode in-iso path

On Fri, 2015-09-18 at 18:50 +0100, Ian Jackson wrote: > ts-debian-hvm-install hardcoded `install.amd' as the directory in the > .iso in which to find the kernel and initrd. This is wrong for > architectures other than amd64. > > Instead, pass this information in runvars (as is done for the

<    1   2