[Xen-devel] [xen-4.5-testing baseline-only test] 37940: regressions - FAIL

This run is configured for baseline tests only. flight 37940 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/37940/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 16

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

> -Original Message- > From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George > Dunlap > Sent: Thursday, September 17, 2015 12:57 AM > To: Jan Beulich > Cc: Wu, Feng; Tian, Kevin; Keir Fraser; Andrew Cooper; Dario Faggioli; > xen-devel@lists.xen.org > Subject: Re:

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

flight 62015 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62015/ 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. 61745

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

> -Original Message- > From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George > Dunlap > Sent: Thursday, September 17, 2015 1:08 AM > To: Wu, Feng > Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper; Dario Faggioli; > xen-devel@lists.xen.org > Subject: Re:

Re: [Xen-devel] [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

On 17.09.2015 00:31, Andrew Cooper wrote: > On 16/09/2015 22:59, Konrad Rzeszutek Wilk wrote: >> On September 16, 2015 5:41:26 PM EDT, Andrew Cooper >> wrote: >>> On 16/09/2015 22:01, Konrad Rzeszutek Wilk wrote: From: Martin Pohlack

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

* Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over bugs. In particular,

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

>>> On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap wrote: > On 09/08/2015 03:17 PM, Ian Campbell wrote: > > On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: > > > > Sorry for the delay, between 4.6 freeze crunch, conference and

Re: [Xen-devel] [xen-unstable test] 62004: regressions - FAIL

On Thu, 2015-09-17 at 01:22 +, osstest service owner wrote: > flight 62004 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/62004/ > > test-amd64-amd64-libvirt-pairpass > test-amd64-i386-libvirt-pair

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

>>> On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap wrote: > On 09/08/2015 03:17 PM, Ian Campbell wrote: > > On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: > > > > Sorry for the delay, between 4.6 freeze crunch, conference and

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: Thursday, September 17, 2015 1:18 AM > To: Wu, Feng > Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew > Cooper; Jan Beulich > Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx:

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/15 00:33, Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over bugs. In particular, KVM

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: Thursday, September 17, 2015 4:48 PM > To: Wu, Feng > Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew > Cooper; Jan Beulich > Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx:

Re: [Xen-devel] [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

On 17/09/15 07:41, Martin Pohlack wrote: > On 17.09.2015 00:31, Andrew Cooper wrote: >> On 16/09/2015 22:59, Konrad Rzeszutek Wilk wrote: >>> On September 16, 2015 5:41:26 PM EDT, Andrew Cooper >>> wrote: On 16/09/2015 22:01, Konrad Rzeszutek Wilk wrote: >

[Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

This is the xl/xc changes to support Intel Code/Data Prioritization. CAT xl commands to set/get CBMs are extended to support CDP. Signed-off-by: He Chen --- tools/libxc/include/xenctrl.h | 7 +-- tools/libxc/xc_psr.c | 17 ++-

[Xen-devel] [PATCH v4 1/4] x86: Support enable CDP by boot parameter and add get CDP status

Add boot parameter `psr=cdp` to enable CDP at boot time. Intel Code/Data Prioritization(CDP) feature is based on CAT. Note that cos_max would be half when CDP is on. struct psr_cat_cbm is extended to support CDP operation. Extend psr_get_cat_l3_info sysctl to get CDP status. Signed-off-by: He

[Xen-devel] [PATCH v4 0/4] detect and initialize CDP (Code/Data Prioritization) feature

Changes in v4: - x86: * remove union member name in struct `psr_cat_cbm` (suggested by Jan) * fix log info of CAT & CDP (suggested by Chao & Jan) * add a helper `cdp_is_enabled` to tell the status of CDP and CDP initialize failed is considered (Jan's comment) *

[Xen-devel] [PATCH v4 4/4] docs: add document to introduce CDP command

Add new CDP options with CAT commands in xl interface man page. Add description of CDP in xl-psr.markdown. Signed-off-by: He Chen --- docs/man/xl.pod.1 | 14 ++ docs/misc/xl-psr.markdown | 44 +++- 2 files

[Xen-devel] [PATCH v4 2/4] x86: add domctl cmd to set/get CDP code/data CBM

CDP extends CAT and provides the capacity to control L3 code & data cache. With CDP, one COS corresponds to two CMBs(code & data). cbm_type is added to distinguish different CBM operations. Besides, new domctl cmds are introdunced to support set/get CDP CBM. Some CAT functions to operation CBMs

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

On 09/17/2015 09:19 AM, Chun Yan Liu wrote: > > On 9/9/2015 at 12:52 AM, in message <55ef1244@citrix.com>, George Dunlap > wrote: >> On 09/08/2015 03:17 PM, Ian Campbell wrote: >>> On Mon, 2015-08-10 at 18:35 +0800, Chunyan Liu wrote: >>> >>> Sorry

Re: [Xen-devel] [OSSTest Nested v12 00/21] Introduction of netsted HVM test job

Hu, Robert writes ("RE: [OSSTest Nested v12 00/21] Introduction of netsted HVM test job"): > [Ian Jackson:] > > Sorry for the delay in reviewing the last few patches in this series. > > I've finished with it now. I hope my previous review comments > > etc. have been helpful. > > Though just took

Re: [Xen-devel] Notes from Xen BoF at Debconf15

On Tue, Sep 8, 2015 at 3:49 PM, Doug Goldstein wrote: >> Stubdomains >> === >> >> Hard to do in a packaging environment (is really its own partial >> architecture). Rump kernels are no different in this regard. >> >> No clever ideas were put forward. > > Honestly what

[Xen-devel] [PATCH] MAINTAINERS: Split out maintainers for the hypervisor

This is a copy of the `THE REST' entry but with my own entry removed, as I do not normally review hypervisor patches. I have chosen to be conservative and make a minimal change, rather than trying to describe a desirable state, or reflect reality. The obvious questions to me, that I have not

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

Julien Grall writes ("Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device"): > On 16/09/2015 14:47, Ian Jackson wrote: > > I don't consider myself qualified to review that. I think the > > MAINTAINERS file should have an entry for xen/ but it doesn't seem to. > >

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 11:31, Borislav Petkov wrote: > >> > Crashing the bootup on an unknown MSR is bad. Many MSR reads and writes >> > are >> > non-critical and returning the 'safe' result is much better than crashing >> > or >> > hanging the bootup. > ... and prepending all MSR accesses with

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

Convert existing cpu_has_x??? to being functions of boot_cpu_data (matching the prevailing style), and mask out unsupported features. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Shuai Ruan This is another patch

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 10:58, Peter Zijlstra wrote: > But the far greater problem I have with the whole virt thing is that > you cannot use rdmsr_safe() to probe if an MSR exists at all because, as > you told me, these virt thingies return 0 for all 'unknown' MSRs instead > of faulting. At least for

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

On 09/17/2015 10:38 AM, George Dunlap wrote: > Is it the case that the interrupt is not actually delivered to the > processor, but that the pending bit will be set in the pi field, so that > the interrupt will be delivered the next time the hypervisor returns > into the guest? > > (I am assuming

Re: [Xen-devel] Newbie

Cc Lars On Thu, Sep 17, 2015 at 02:33:43PM +0530, Lasya Venneti wrote: > Hi everyone, > > I'm Lasya a student studying in IIIT-H, Hyderabad, India. > > I wish to participate in round 11 of Outreachy this time. I would be > grateful if someone would direct me as to how I am supposed to start >

Re: [Xen-devel] [PATCH v2 for-4.6] libxl: handle read-only drives with qemu-xen

On Thu, 2015-09-17 at 12:35 +0100, Wei Liu wrote: > On Thu, Sep 17, 2015 at 12:13:20PM +0100, Ian Campbell wrote: > > On Wed, 2015-09-16 at 14:54 +0100, Ian Jackson wrote: > > > M A Young writes ("Re: [PATCH v2 for-4.6] libxl: handle read-only > > > drives > > > with qemu-xen"): > > > > On Tue, 15

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On Wed, 16 Sep 2015, Chen, Tiejun wrote: > On 9/15/2015 7:00 PM, Paolo Bonzini wrote: > > > > > > On 15/09/2015 11:55, Stefano Stabellini wrote: > > > On Mon, 14 Sep 2015, Paolo Bonzini wrote: > > > > > On 10/09/2015 12:29, Stefano Stabellini wrote: > > > > > > > +if (lseek(config_fd, pos,

[Xen-devel] [PATCH v2] MAINTAINERS: Document maintainers for xen/common/

This is a copy of the `THE REST' entry but with my own entry removed (as I do not normally review hypervisor patches) and Andrew Cooper's added (which seems appropriate given his status as x86 hypervisor maintainer). The effect is that patches touching xen/common/ will no longer be CC'd to me;

Re: [Xen-devel] [PATCH v2] MAINTAINERS: Document maintainers for xen/common/

On 17/09/15 12:53, Ian Jackson wrote: > This is a copy of the `THE REST' entry but with my own entry removed > (as I do not normally review hypervisor patches) and Andrew Cooper's > added (which seems appropriate given his status as x86 hypervisor > maintainer). > > The effect is that patches

Re: [Xen-devel] [PATCH] x86/sysctl: Don't clobber memory if NCAPINTS > ARRAY_SIZE(pi->hw_cap)

On Wed, 2015-09-16 at 16:01 +0100, Wei Liu wrote: > On Wed, Sep 16, 2015 at 10:01:45AM +0100, Andrew Cooper wrote: > > There is no current problem, as both NCAPINTS and pi->hw_cap are 8 > > entries, > > but the limit should be calculated appropriately so as to avoid > > hypervisor > > stack

Re: [Xen-devel] [PATCH] pci-attach: fix assertation

On Wed, 2015-09-16 at 15:08 +0100, Wei Liu wrote: > On Wed, Sep 16, 2015 at 09:25:25AM +0100, Ian Campbell wrote: > > On Wed, 2015-09-16 at 14:16 +0800, Chunyan Liu wrote: > > > > For the subject I prefer to avoid "fix " style messages. In this > > case something like "libxl: ensure xs

Re: [Xen-devel] Newbie - OutreachY round 11 (Dec 7 to March 7)

Hi all, we do have two OutreachY slots and I just received information related about the timeline for OutreachY yesterday. See below September 28 organizations' landing pages need to be ready with project ideas September 29 application process opens November 2 application deadline November 17

Re: [Xen-devel] [PATCH v2] MAINTAINERS: Document maintainers for xen/common/

On 17/09/15 12:59, Andrew Cooper wrote: > On 17/09/15 12:53, Ian Jackson wrote: >> This is a copy of the `THE REST' entry but with my own entry removed >> (as I do not normally review hypervisor patches) and Andrew Cooper's >> added (which seems appropriate given his status as x86 hypervisor >>

Re: [Xen-devel] [PATCH v2 for-4.6] libxl: handle read-only drives with qemu-xen

On Thu, Sep 17, 2015 at 12:49:41PM +0100, Ian Campbell wrote: [...] > > > So shall we go ahead with this for 4.6 or is there more > > > testing/discussion/whatever needed? > > > > > > > Yes, of course. > > "Yes, of course, go ahead" or "Yes, of course, more > testing/discusion/whatever is

Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

Hi, >From the comments on this patch, IIUC, we don't object to the change brought by this patch. What we didn't reach an agreement is how to support runtime service for Dom0. Right? If so, I think this patch doesn't conflict with adding support for runtime service in the future. So could we move

Re: [Xen-devel] [PATCH v4 1/4] x86: Support enable CDP by boot parameter and add get CDP status

On 17/09/15 10:35, He Chen wrote: > Add boot parameter `psr=cdp` to enable CDP at boot time. > Intel Code/Data Prioritization(CDP) feature is based on CAT. Note that > cos_max would be half when CDP is on. struct psr_cat_cbm is extended to > support CDP operation. Extend psr_get_cat_l3_info sysctl

Re: [Xen-devel] [PATCH] MAINTAINERS: Split out maintainers for the hypervisor

Hi Ian, On 17/09/15 11:16, Ian Jackson wrote: > This is a copy of the `THE REST' entry but with my own entry removed, > as I do not normally review hypervisor patches. > > I have chosen to be conservative and make a minimal change, rather > than trying to describe a desirable state, or reflect

Re: [Xen-devel] [PATCH v4 2/4] x86: add domctl cmd to set/get CDP code/data CBM

On 17/09/15 10:35, He Chen wrote: > @@ -375,10 +401,48 @@ static int write_l3_cbm(unsigned int socket, unsigned > int cos, > return 0; > } > > -int psr_set_l3_cbm(struct domain *d, unsigned int socket, uint64_t cbm) > +static int find_cos(struct psr_cat_cbm *map, int cos_max, > +

Re: [Xen-devel] [PATCH XEN] Config: Switch to unified qemu trees.

Ian Campbell writes ("[PATCH XEN] Config: Switch to unified qemu trees."): > Upstream qemu is not in qemu-xen.git and the trad fork is in > qemu-xen-traditional.h > > QEMU_UPSTREAM_REVISION is currently a tag and > QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are > required to

Re: [Xen-devel] [PATCH] MAINTAINERS: Split out maintainers for the hypervisor

Julien Grall writes ("Re: [PATCH] MAINTAINERS: Split out maintainers for the hypervisor"): > There is a slight problem with this change. The group "REST OF THE > HYPERVISOR" is now CCed to any file under xen. Eeek. (Dropping many of the CCs.) > I suspect this is a bug in get_maintainers.pl

Re: [Xen-devel] [PATCH v4 3/4] tools: add tools support for Intel CDP

On 17/09/15 10:35, He Chen wrote: > @@ -2798,7 +2798,9 @@ enum xc_psr_cmt_type { > typedef enum xc_psr_cmt_type xc_psr_cmt_type; > > enum xc_psr_cat_type { > -XC_PSR_CAT_L3_CBM = 1, > +XC_PSR_CAT_L3_CBM = 1, > +XC_PSR_CAT_L3_CODE = 2, > +XC_PSR_CAT_L3_DATA = 3, > }; No need

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

On Thu, 2015-09-17 at 11:43 +0100, Ian Campbell wrote: > > > +qemu-upstream-*-testing) > > ... > > > + # For now also push to the old split trees for historical > > > + # branches only (qemu-upstream started with xen-4.2-testing > > > + # and the split trees end at xen-4.6-testing) > > > + case

Re: [Xen-devel] [PATCH v2 for-4.6] libxl: handle read-only drives with qemu-xen

On Wed, 2015-09-16 at 14:54 +0100, Ian Jackson wrote: > M A Young writes ("Re: [PATCH v2 for-4.6] libxl: handle read-only drives > with qemu-xen"): > > On Tue, 15 Sep 2015, Stefano Stabellini wrote: > > Is ERROR_INVAL the right error to return? I get > > > > libxl_dm.c: In function

Re: [Xen-devel] [PATCH] MAINTAINERS: Split out maintainers for the hypervisor

(cutting Cc to just those listed as REST plus Julien who suggested this change) On Thu, 2015-09-17 at 11:16 +0100, Ian Jackson wrote: > This is a copy of the `THE REST' entry but with my own entry removed, > as I do not normally review hypervisor patches. > > I have chosen to be conservative and

Re: [Xen-devel] [PATCH v2 for-4.6] libxl: handle read-only drives with qemu-xen

On Thu, 17 Sep 2015, Ian Campbell wrote: > On Wed, 2015-09-16 at 14:54 +0100, Ian Jackson wrote: > > M A Young writes ("Re: [PATCH v2 for-4.6] libxl: handle read-only drives > > with qemu-xen"): > > > On Tue, 15 Sep 2015, Stefano Stabellini wrote: > > > Is ERROR_INVAL the right error to return? I

Re: [Xen-devel] [PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)

Ian Campbell writes ("[PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)"): > As discussed[0] I think we should move away from having a pair of qemu > repositories for each Xen branch and instead have a single pair (one for > qemu-xen and one for

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

Ian Campbell writes ("[PATCH OSSTEST] Switch to merged qemu-xen{,-traditional}.git trees"): > The qemu-mainline flights now push to the upstream-tested branch of > qemu-xen.git (while still pulling from upstream). This mostly looks fine. How are we going to test this ? I think the most

Re: [Xen-devel] [PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)

On Thu, 2015-09-17 at 11:23 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree > per qemu version (trad vs upstream)"): > > I believe the plan for deployment should be: > > > > * Today we can already just remove the old staging/qemu-xen-*

Re: [Xen-devel] [PATCH XEN] Config: Switch to unified qemu trees.

On Thu, 2015-09-17 at 11:32 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH XEN] Config: Switch to unified qemu > trees."): > > Upstream qemu is not in qemu-xen.git and the trad fork is in > > qemu-xen-traditional.h > > > > QEMU_UPSTREAM_REVISION is currently a tag and > >

Re: [Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

On Thu, 2015-09-17 at 11:31 +0100, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST] Switch to merged qemu-xen{, > -traditional}.git trees"): > > The qemu-mainline flights now push to the upstream-tested branch of > > qemu-xen.git (while still pulling from upstream). > > This mostly

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

However, the difference between one CONFIG and another is quite frankly crazy. We should explicitly use the safe versions where this is appropriate, and then yes, we should do this. Yet another reason the paravirt code is batshit crazy. On September 17, 2015 2:31:34 AM PDT, Borislav Petkov

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

>>> On 9/14/2015 at 10:03 PM, in message , George Dunlap wrote: > On Mon, Sep 14, 2015 at 12:12 PM, Ian Jackson > wrote: > > Juergen Gross writes ("Re: [Xen-devel]

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Wed, Sep 16, 2015 at 04:33:11PM -0700, Andy Lutomirski wrote: > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. > > This is IMO awful: it papers over

[Xen-devel] Newbie

Hi everyone, I'm Lasya a student studying in IIIT-H, Hyderabad, India. I wish to participate in round 11 of Outreachy this time. I would be grateful if someone would direct me as to how I am supposed to start contributing to Xen Project for this Outreachy round. Sincerely, Lasya V

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 09:19:20AM +0200, Ingo Molnar wrote: > Most big distro kernels on bare metal have CONFIG_PARAVIRT=y (I checked > Ubuntu and > Fedora), so we are potentially exposing a lot of users to problems. + SUSE. > Crashing the bootup on an unknown MSR is bad. Many MSR reads and

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

On 09/17/2015 10:38 AM, George Dunlap wrote: > On 09/17/2015 09:48 AM, Dario Faggioli wrote: >> On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote: >> -Original Message- From: Dario Faggioli [mailto:dario.faggi...@citrix.com] >> So, I guess, first of all, can you confirm

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

On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote: > > -Original Message- > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > > So, I guess, first of all, can you confirm whether or not it's exploding > > in debug builds? > > Does the following information in Config.mk mean it

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

On 16/09/2015 14:47, Ian Jackson wrote: Julien Grall writes ("Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device"): On 16/09/15 11:46, Ian Jackson wrote: JOOI why did you CC me ? I did a quick scan of these patches and they don't seem to have any tools

[Xen-devel] [PATCH OSSTEST] Switch to merged qemu-xen{, -traditional}.git trees

The qemu-mainline flights now push to the upstream-tested branch of qemu-xen.git (while still pulling from upstream). The qemu-upstream-unstable flights pull from staging and push to master in qemu-xen.git All of the qemu-upstream-X.Y-testing pull from staging-X.Y and push to stable-X.Y branch

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

On 09/17/2015 09:48 AM, Dario Faggioli wrote: > On Thu, 2015-09-17 at 08:00 +, Wu, Feng wrote: > >>> -Original Message- >>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > >>> So, I guess, first of all, can you confirm whether or not it's exploding >>> in debug builds? >>

[Xen-devel] [PATCH XEN] Config: Switch to unified qemu trees.

Upstream qemu is not in qemu-xen.git and the trad fork is in qemu-xen-traditional.h QEMU_UPSTREAM_REVISION is currently a tag and QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are required to those. Signed-off-by: Ian Campbell (cherry picked from

[Xen-devel] [PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)

As discussed[0] I think we should move away from having a pair of qemu repositories for each Xen branch and instead have a single pair (one for qemu-xen and one for qemu-xen-traditional). I've prepared a pair of repositories:

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

flight 62022 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/62022/ 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. 61513 Tests which are

Re: [Xen-devel] [RFC PATCH 0/5] Load BIOS via toolstack instead of been embedded in hvmloader.

On Wed, Sep 16, 2015 at 07:56:44PM +0100, Andrew Cooper wrote: > On 16/09/2015 18:19, Anthony PERARD wrote: > > Hi all, > > > > I've start to look at loading the BIOS and the ACPI tables via the > > toolstack instead of having them embedded in the hvmloader binary. This is > > done by using the

Re: [Xen-devel] [PATCH v2] MAINTAINERS: Document maintainers for xen/common/

At 12:53 +0100 on 17 Sep (1442494439), Ian Jackson wrote: > This is a copy of the `THE REST' entry but with my own entry removed > (as I do not normally review hypervisor patches) and Andrew Cooper's > added (which seems appropriate given his status as x86 hypervisor > maintainer). > > The effect

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 01:40:30PM +0200, Paolo Bonzini wrote: > > > On 17/09/2015 10:58, Peter Zijlstra wrote: > > But the far greater problem I have with the whole virt thing is that > > you cannot use rdmsr_safe() to probe if an MSR exists at all because, as > > you told me, these virt

[Xen-devel] [xen-unstable baseline-only test] 37938: tolerable FAIL

This run is configured for baseline tests only. flight 37938 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/37938/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop

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

On Thu, Sep 17, 2015 at 06:44:05AM +, osstest service owner wrote: > flight 62015 xen-4.6-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/62015/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

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

On Thu, 2015-09-17 at 12:44 +0100, George Dunlap wrote: > On 09/17/2015 10:38 AM, George Dunlap wrote: > > Is it the case that the interrupt is not actually delivered to the > > processor, but that the pending bit will be set in the pi field, so that > > the interrupt will be delivered the next

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

On Thu, 2015-09-17 at 13:40 +0100, Wei Liu wrote: > On Thu, Sep 17, 2015 at 06:44:05AM +, osstest service owner wrote: > > flight 62015 xen-4.6-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/62015/ > > > > Regressions :-( > > > > Tests which did not succeed and are

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 08:17:18AM -0700, Andy Lutomirski wrote: > > Ah, that would be good news. Andy earlier argued I could not rely on > > rdmsr_safe() faulting on unknown MSRs. If practically we can there's > > some code I can simplify :-) > > I was taking about QEMU TCG, not KVM. Just for

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 8:17 AM, Peter Zijlstra wrote: > On Thu, Sep 17, 2015 at 08:17:18AM -0700, Andy Lutomirski wrote: > >> > Ah, that would be good news. Andy earlier argued I could not rely on >> > rdmsr_safe() faulting on unknown MSRs. If practically we can there's >>

Re: [Xen-devel] [PATCH v5 2/9] x86/intel_pstate: APERF/MPERF feature detect

On 14/09/15 03:32, Wei Wang wrote: > Add support to detect the APERF/MPERF feature. Also, remove the identical > code in cpufreq.c and powernow.c. This patch is independent of the > earlier patches. > > Signed-off-by: Wei Wang Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH OSSTEST 3/4] ms-queuedaemon: Add report-projection

No semantic change. Eventually more tasks will be added which are wanted in report-projection but not report-plan. Signed-off-by: Ian Campbell --- ms-queuedaemon | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/ms-queuedaemon b/ms-queuedaemon

Re: [Xen-devel] [PATCH 1/4] x86/EPT: always return proper order value from ept_get_entry()

On 15/09/15 08:30, Jan Beulich wrote: > This is so that callers can determine what range of address space would > get altered by a corresponding "set". > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH OSSTEST 4/4] ms-queuedaemon: Call ms-flights-summary upon completed plan/projection

Signed-off-by: Ian Campbell --- ms-queuedaemon | 13 + 1 file changed, 13 insertions(+) diff --git a/ms-queuedaemon b/ms-queuedaemon index 9c7645d..6ae9677 100755 --- a/ms-queuedaemon +++ b/ms-queuedaemon @@ -310,7 +310,20 @@ proc report-plan {w wo} { }

Re: [Xen-devel] [PATCH OSSTEST v4] ms-flights-summary: Produce an HTML report of all active flights

On Wed, 2015-09-16 at 14:07 +0100, Ian Campbell wrote: > TODO: Hook up to ms-queuedaemon to run when a new projection is > complete. I will followup to this with 4 patches (including 2 from you) which do this. They are currently live in the Cambridge daemons-testing.git and successfully

[Xen-devel] [PATCH OSSTEST 2/4] ms-queuedaemon: Break out catching-internally

From: Ian Jackson No functional change. Signed-off-by: Ian Jackson --- ms-queuedaemon | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/ms-queuedaemon b/ms-queuedaemon index 1a31284..f3f85bd 100755

[Xen-devel] [PATCH for-4.6] HACK: Use my local trees

--- .config | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.config b/.config index 8258faa..9b808a2 100644 --- a/.config +++ b/.config @@ -1,5 +1,5 @@ -MINIOS_UPSTREAM_URL := git://xenbits.xen.org/people/ianc/mini-os.git -MINIOS_UPSTREAM_REVISION :=

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

On Thu, 2015-09-17 at 15:30 +0100, George Dunlap wrote: > On 09/17/2015 01:40 PM, Dario Faggioli wrote: > >> I haven't yet decided whether I prefer my original suggestion of > >> switching the interrupt and putting things on the wake-up list in > >> vcpu_block(), or of deferring adding things to

Re: [Xen-devel] [PATCH v5 5/9] x86/intel_pstate: changes in cpufreq_del_cpu for CPU offline

On 14/09/15 03:32, Wei Wang wrote: > We change to NULL the cpufreq_cpu_policy pointer after the call of > cpufreq_driver->exit, because the pointer is still needed in > intel_pstate_set_pstate(). > > Signed-off-by: Wei Wang > --- > xen/drivers/cpufreq/cpufreq.c | 6

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 17:26, Andy Lutomirski wrote: > Maybe Paolo can fix QEMU to fail bad MSR accesses for real... I was afraid of someone proposing exactly that. :) I can do it since the list of MSRs can be lifted from KVM. Let's first see the direction these patches go... Paolo

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like native_read_msr_safe doesn't clear the output if the rdmsr fails. I'd suggest to return some poison not

Re: [Xen-devel] [PATCH for-4.6] INSTALL: Mention MINIOS_UPSTREAM_URL

On Thu, Sep 17, 2015 at 05:30:50PM +0100, Ian Campbell wrote: > All the other ones seem to be there. > > Signed-off-by: Ian Campbell > --- > For 4.6: trivially Documentation update is safe to go in. Release-acked-by: Wei Liu > --- > INSTALL | 1

Re: [Xen-devel] [PATCH OSSTEST 3/4] ms-queuedaemon: Add report-projection

Ian Campbell writes ("[PATCH OSSTEST 3/4] ms-queuedaemon: Add report-projection"): > No semantic change. Eventually more tasks will be added which are > wanted in report-projection but not report-plan. Acked-by: Ian Jackson Though you might want to avoid the word

Re: [Xen-devel] [PATCH v5 6/9] x86/intel_pstate: the main boby of the intel_pstate driver

On 14/09/15 03:32, Wei Wang wrote: > We simply grab the fundamental logic of the intel_pstate driver > from Linux kernel, and customize it to Xen style. How much customisation? Is it just style, or other additions as well? (Deletions are less interesting) For files we import directly from

Re: [Xen-devel] [PATCH for-4.6] HACK: Use my local trees

On Thu, 2015-09-17 at 17:28 +0100, Ian Campbell wrote: Sorry, wrong patch, please ignore > --- > .config | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/.config b/.config > index 8258faa..9b808a2 100644 > --- a/.config > +++ b/.config > @@ -1,5 +1,5 @@ >

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 12:19 AM, Ingo Molnar wrote: > > * Andy Lutomirski wrote: > >> Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently >> turns all rdmsr and wrmsr operations into the safe variants without >> any checks that the operations

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/15 16:27, Borislav Petkov wrote: > On Thu, Sep 17, 2015 at 01:39:26PM +0200, Paolo Bonzini wrote: >> That's not a big deal, that's what *_safe is for. The problem is that >> there are definitely some cases where the *_safe version is not being used. > I mean to do feature checks which

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 17:31, Arjan van de Ven wrote: >> >> What about 0 + WARN? > > why 0? > > 0xdeadbeef or any other pattern (even 0x3636363636) makes more sense (of > course also WARN... but most folks don't read dmesg for WARNs) > > (it's the same thing we do for list or slab poison stuff)

Re: [Xen-devel] [PATCH v4 1/5] sched: factor out VCPU2ONLINE to common header file

On Sun, 2015-07-12 at 22:13 -1000, Justin T. Weaver wrote: > Move macro VCPU2ONLINE from schedule.c to sched.h so it can be used by other > source files. > "No functional changes intended." > Signed-off-by: Justin T. Weaver > (with the above) Reviewed-by: Dario Faggioli

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On Thu, Sep 17, 2015 at 04:32:53PM +0100, Andrew Cooper wrote: > There are plenty of non-architectural MSRs in use which don't have > feature bits. That's exactly what the "possible" adjective was supposed to represent. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

Re: [Xen-devel] [PATCH v5 4/9] x86/intel_pstate: relocate the driver register function

On 14/09/15 03:32, Wei Wang wrote: > Move the driver register function to > the cpufreq.c. > > Signed-off-by: Wei Wang > --- > xen/drivers/cpufreq/cpufreq.c | 15 +++ > xen/include/acpi/cpufreq/cpufreq.h | 27 +-- > 2 files changed,

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 9/17/2015 8:29 AM, Paolo Bonzini wrote: On 17/09/2015 17:27, Arjan van de Ven wrote: ( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like

Re: [Xen-devel] [PATCH v5 1/9] x86/intel_pstate: add some calculation related support

On 14/09/15 03:32, Wei Wang wrote: > The added calculation related functions will be used in the intel_pstate.c. > They are copied from the Linux kernel(commit 2418f4f2, f3002134, eb18cba7). > > Signed-off-by: Wei Wang > --- > xen/arch/x86/oprofile/op_model_athlon.c | 9

Re: [Xen-devel] [PATCH v5 7/9] x86/intel_pstate: add a booting param to select the driver to load

On 14/09/15 03:32, Wei Wang wrote: > By default, the old P-state driver (acpi-freq) is used. Adding > "intel_pstate" to the Xen booting param list to enable the > use of intel_pstate. However, if intel_pstate is enabled on a > machine which does not support the driver (e.g. Nehalem), the > old

Re: [Xen-devel] [xen-unstable test] 62004: regressions - FAIL

On 09/17/2015 01:07 AM, Ian Campbell wrote: On Thu, 2015-09-17 at 01:22 +, osstest service owner wrote: flight 62004 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/62004/ test-amd64-amd64-libvirt-pairpass

  1   2   3   >