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
* 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 gueests
> migh
> -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:
>>> 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 vacation
> > I've been a bi
>>> 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 vacation
> > I've been a bi
>>> 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] [PATCH V6 3/7] libxl: add pvusb
> API"):
> >> On 09/14/2015 12:36 PM, George Dunlap wrote:
> >> > Anyone want to look into
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
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 bug
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
__
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 impac
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 g
> -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:
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 wr
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:
> From: Martin Pohlack
>
>>>
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 ++-
tools/libxl/libxl.h | 7 +++
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 Chen
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_SYSCTL_INTERFACE_VERS
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 changed, 53 insertions(+), 5 d
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 are
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:
http://xenbits.xen.org/gitweb/?p=people/ianc/single-qemu-repo/qemu
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 commit dff5c395c1d23c21238ce17d
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 in
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?
>>
>>
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 wheth
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 f
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 sam
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 for the delay, between 4.6
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
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 about moving these mo
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 answ
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.
>
>
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
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
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 qemu-xen-trad
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,
> +
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 practica
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 t
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 beca
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-* trees
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 f
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
> > QEMU_TRADITIONA
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 looks
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 "$x
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 'libxl__build_d
(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
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 wr
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
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 Sep 2015, Stefano Stabellini wrote:
> > > Is ERROR_INVAL the right
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 featu
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 from my feature levelling series which is being posted
early because of in
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 KVM,
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 t
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
> co
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
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, SE
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; but
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 touch
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 corrupt
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 transaction
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 acc
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 needed
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
>> mai
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 t
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
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 thingie
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
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:
> test-amd64
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 tim
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 b
Hi all,
the AB is sponsoring 2 interns again for the winter round
This means we need to update the following pages by September 28
* All: http://wiki.xenproject.org/wiki/Outreach_Program_Projects - aka add new
projects/remove old ones
* MirageOS: http://wiki.xenproject.org/wiki/Outreach_Program_
Signed-off-by: Mike Belopuhov
---
xen/include/public/arch-x86/pmu.h | 22 ++
xen/include/public/hvm/e820.h | 3 ++-
xen/include/public/hvm/hvm_info_table.h | 2 ++
xen/include/public/hvm/hvm_op.h | 2 ++
xen/include/public/hvm/hvm_xs_strings.h | 2 +
On 09/17/2015 03:59 PM, Andrew Cooper wrote:
> On 15/09/15 10:19, Razvan Cojocaru wrote:
>> Previously, if vm_event emulation support was enabled, then REP
>> optimizations were disabled when emulating REP-compatible
>> instructions. This patch allows fine-tuning of this behaviour by
>> providing a
On 15/09/15 10:19, Razvan Cojocaru wrote:
> Previously, if vm_event emulation support was enabled, then REP
> optimizations were disabled when emulating REP-compatible
> instructions. This patch allows fine-tuning of this behaviour by
> providing a dedicated libxc helper function.
>
> Signed-off-by
On 17/09/15 14:20, Razvan Cojocaru wrote:
> On 09/17/2015 03:59 PM, Andrew Cooper wrote:
>> On 15/09/15 10:19, Razvan Cojocaru wrote:
>>> Previously, if vm_event emulation support was enabled, then REP
>>> optimizations were disabled when emulating REP-compatible
>>> instructions. This patch allows
flight 37941 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-wheezy-netboot-pygrub 7 host-ping-check-xen fail REGR.
vs. 37918
On 09/17/2015 04:37 PM, Andrew Cooper wrote:
> On 17/09/15 14:20, Razvan Cojocaru wrote:
>> On 09/17/2015 03:59 PM, Andrew Cooper wrote:
>>> On 15/09/15 10:19, Razvan Cojocaru wrote:
Previously, if vm_event emulation support was enabled, then REP
optimizations were disabled when emulating
flight 62028 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62028/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 61666
test-amd64-amd64-xl
flight 62023 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62023/
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. 58581
Regressions which are
On Wed, 2015-03-25 at 23:48 -1000, Justin T. Weaver wrote:
> Here are the results I gathered from testing. Each guest had 2 vcpus and 1GB
> of memory.
>
Hey, thanks for doing the benchmarking as well! :-)
> The hardware consisted of two quad core Intel Xeon X5570 processors
> and 8GB of RAM per
On 09/17/2015 01:40 PM, Dario Faggioli wrote:
> 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
Ian Campbell writes ("Re: [Xen-devel] [xen-4.6-testing test] 62015: regressions
- FAIL"):
> This has failed twice in a row on xen-4.6-testing, in 61839 and here. The
> bisector already had a go at the initial failure, but concluded
> unreproducible as shown by the yellow box in
>
> http://logs.te
Ian Jackson writes ("Re: [Xen-devel] [xen-4.6-testing test] 62015: regressions
- FAIL"):
> Ian Campbell writes ("Re: [Xen-devel] [xen-4.6-testing test] 62015:
> regressions - FAIL"):
> > This has failed twice in a row on xen-4.6-testing, in 61839 and here. The
> > bisector already had a go at the
---
README.dev | 53 +
1 file changed, 53 insertions(+)
diff --git a/README.dev b/README.dev
index 4df7237..b5344d7 100644
--- a/README.dev
+++ b/README.dev
@@ -165,6 +165,59 @@ $HOME/testing.git/$xenbranch.stop
stops everything using $xenb
On 09/17/2015 05:10 AM, Andrew Cooper wrote:
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
On Thu, 2015-09-17 at 16:27 +0200, Dario Faggioli wrote:
> Nice. Just to be sure, is my understending of the columns label
> accurate?
> - 'No affinity' == no hard nor soft affinity for any VM
> - 'Pinning' == hard affinity used to pin VMs to NUMA nodes
> (eve
Stefano, Anthony,
This looks like a real upstream regression.
On Thu, 2015-09-17 at 13:44 +, osstest service owner wrote:
> flight 62028 qemu-mainline real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62028/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
flight 62029 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62029/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-sup
On Sep 17, 2015 5:33 AM, "Peter Zijlstra" wrote:
>
> 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
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 actually succeed.
>>
>> This is IMO
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 ass
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 m
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
>> > some code I can simpl
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 Linux
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
_
On 14/09/15 03:32, Wei Wang wrote:
> In order to better support future Intel processors, intel_pstate
> changes to use percentage values to tune P-states. The setpolicy
> driver interface is used to configure the intel_pstate internal
> policy. The __cpufreq_set_policy needs to be intercepted to us
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 assure you that those MSRs are
there so you don't
( 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 j
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 +++---
> xen/include/acpi
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
__
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)
Sorry,
1 - 100 of 202 matches
Mail list logo
