On Fri, Jul 24, 2015 at 11:23 PM, Willy Tarreau wrote:
> On Fri, Jul 24, 2015 at 10:36:45PM -0700, Andy Lutomirski wrote:
>> The modify_ldt syscall exposes a large attack surface and is
>> unnecessary for modern userspace. Make it optional.
>
> Andy, you didn't respond whether you think it wouldn
On Fri, Jul 24, 2015 at 10:36:43PM -0700, Andy Lutomirski wrote:
> Willy and Kees: I left the config option alone. The -tiny people will
> like it, and we can always add a sysctl of some sort later.
OK, please ignore my other e-mail I missed this part. I'll see if I
can propose the sysctl complet
On Fri, Jul 24, 2015 at 10:36:45PM -0700, Andy Lutomirski wrote:
> The modify_ldt syscall exposes a large attack surface and is
> unnecessary for modern userspace. Make it optional.
Andy, you didn't respond whether you think it wouldn't be better to make
it runtime-configurable instead. The goal
This tests general modify_ldt behavior (only writes, so far) as
well as synchronous updates via IPI. It fails on old kernels.
I called this ldt_gdt because I'll add set_thread_area tests to
it at some point.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/Makefile | 2 +-
too
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig | 17 +
arch/x86/include/asm/mmu.h | 2 ++
arch/x86/include/asm/mmu_context.h | 31
modify_ldt has questionable locking and does not synchronize
threads. Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.
This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
Here's v3. It fixes the "dazed and confused" issue, I hope. It's also
probably a good general attack surface reduction, and it replaces some
scary code with IMO less scary code.
Also, servers and embedded systems should probably turn off modify_ldt.
This makes that possible.
Xen people, can you
On Fri, Jul 24, 2015 at 9:13 PM, Boris Ostrovsky
wrote:
>
>
> On 07/22/2015 06:20 PM, Boris Ostrovsky wrote:
>>
>> On 07/22/2015 03:23 PM, Andy Lutomirski wrote:
>>>
>>>
>>> +error = -ENOMEM;
>>> +new_ldt = alloc_ldt_struct(newsize);
>>> +if (!new_ldt)
>>> goto out_unlock;
>>
On Fri, Jul 24, 2015 at 8:29 AM, Borislav Petkov wrote:
> Let it stick out:
>
> if (!cpumask_equal(mm_cpumask(current_mm),
> cpumask_of(smp_processor_id(
> smp_call_function(flush_ldt, current_mm, 1);
I see your wide terminal and raise you a complete rewrite of that
f
On 07/22/2015 06:20 PM, Boris Ostrovsky wrote:
On 07/22/2015 03:23 PM, Andy Lutomirski wrote:
+error = -ENOMEM;
+new_ldt = alloc_ldt_struct(newsize);
+if (!new_ldt)
goto out_unlock;
-}
-fill_ldt(&ldt, &ldt_info);
-if (oldmode)
-ldt.avl = 0;
+if
flight 59870 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59870/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-xsm 13 guest-saverestore fail baseline untested
test-amd64-amd64-rumpuserxen-am
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
test guest-saverestore
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbi
Hi David,
On 24/07/2015 12:47, David Vrabel wrote:
Pages returned by alloc_xenballooned_pages() will be used for grant
mapping which will call set_phys_to_machine() (in PV guests).
Ballooned pages are set as INVALID_P2M_ENTRY in the p2m and thus may
be using the (shared) missing tables and a su
On July 24, 2015 6:40:27 PM EDT, Wei Liu wrote:
>Originally there was only one counter to keep track of pages. It was
>used erroneously to keep track of how many pages were mapped and how
>many pages needed to be send. In the
sent
> end munmap(2) always has 0 as the
>length argument, which resu
Originally there was only one counter to keep track of pages. It was
used erroneously to keep track of how many pages were mapped and how
many pages needed to be send. In the end munmap(2) always has 0 as the
length argument, which resulted in leaking the mapping.
This problem is discovered on 32b
On Fri, Jul 24, 2015 at 04:44:36PM +0200, Dario Faggioli wrote:
> On Fri, 2015-07-24 at 12:28 +0200, Juergen Gross wrote:
> > On 07/23/2015 04:07 PM, Dario Faggioli wrote:
>
> > > FWIW, I was thinking that the kernel were a better place, as Juergen is
> > > saying, while now I'm more convinced tha
Friday, July 24, 2015, 8:56:02 PM, you wrote:
> Hi All,
> On my AMD system running xen-unstable (last commit: ),
> after a few restarts of a HVM guest with pci-passthrough i got these on
> shutdown of the guest:
> (never seen this before, so it should be something triggered by a recent
> com
On Fri, Jul 24, 2015 at 11:57:47AM -0700, Greg KH wrote:
> On Fri, Jul 24, 2015 at 05:51:04AM +0200, Juergen Gross wrote:
> > On 07/23/2015 09:08 PM, Greg KH wrote:
> > >On Thu, Jul 23, 2015 at 08:46:17AM +0200, Juergen Gross wrote:
> > >>On 07/23/2015 06:36 AM, Greg KH wrote:
> > >>>On Thu, Jul 23
Hi All,
On my AMD system running xen-unstable (last commit: ),
after a few restarts of a HVM guest with pci-passthrough i got these on
shutdown of the guest:
(never seen this before, so it should be something triggered by a recent
commit)
--
Sander
(probably lost before but that's los
On Fri, Jul 24, 2015 at 05:51:04AM +0200, Juergen Gross wrote:
> On 07/23/2015 09:08 PM, Greg KH wrote:
> >On Thu, Jul 23, 2015 at 08:46:17AM +0200, Juergen Gross wrote:
> >>On 07/23/2015 06:36 AM, Greg KH wrote:
> >>>On Thu, Jul 23, 2015 at 06:04:39AM +0200, Juergen Gross wrote:
> On 07/23/201
On Fri, Jul 24, 2015 at 12:47:46PM +0100, David Vrabel wrote:
> alloc_xenballooned_pages() is used to get ballooned pages to back
> foreign mappings etc. Instead of having to balloon out real pages,
> use (if supported) hotplugged memory.
>
> This makes more memory available to the guest and redu
On Fri, Jul 24, 2015 at 12:47:43PM +0100, David Vrabel wrote:
> The stats used for memory hotplug make no sense and are fiddled with
> in odd ways. Remove them and introduce total_pages to track the total
> number of pages (both populated and unpopulated) including those within
> hotplugged region
On Fri, Jul 24, 2015 at 12:47:47PM +0100, David Vrabel wrote:
> Rename alloc_p2m() to xen_alloc_p2m_entry() and export it.
>
> This is useful for ensuring that a p2m entry is allocated (i.e., not a
> shared missing or identity entry) so that subsequent set_phys_to_machine()
> calls will require no
On 07/23/2015 10:21 AM, Jan Beulich wrote:
On 11.07.15 at 00:20, wrote:
Signed-off-by: Boris Ostrovsky
---
Changes in v3:
* Defined compat_mmuext_op(). (XEN_GUEST_HANDLE_PARAM(mmuext_op_compat_t)
is not defined in header files so I used 'void' type.
How is it not? It's in compat/xen.h (whi
flight 59850 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 12 guest-saverestore fail REGR. vs. 59059
test-amd64-i386-xl-
On 07/23/2015 10:07 AM, Jan Beulich wrote:
On 11.07.15 at 00:20, wrote:
Add is_pvh_32bit_domain() macro and use it alongside is_pv_32bit_domain()
where necessary.
Since PVH guests cannot change execution mode, has_32bit_shinfo is a good
indicator of whether the guest is PVH and 32-bit.
Signed
On Fri, Jul 24, 2015 at 06:54:09PM +0200, Roger Pau Monné wrote:
> El 24/07/15 a les 17.49, Jan Beulich ha escrit:
> On 24.07.15 at 17:26, wrote:
> >> El 24/07/15 a les 14.44, Jan Beulich ha escrit:
> >> On 24.07.15 at 14:11, wrote:
> Or your idea was to put all the bitness specific
Ian Campbell writes ("[PATCH OSSTEST] xl: Use _VerboseCommand for
save/restore/migrate"):
> Additional logging is as useful here as for create.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Campbell writes ("[PATCH OSSTEST 3/3] ts-debian-hvm-install: Use xargs -0
to avoid massive filelist in logs."):
> The current arrangement is a bit odd, I'm not sure why it would be
> that way and it results in a huge list of files in the middle of the
> log which is rather boring to scroll thr
Ian Campbell writes ("[PATCH OSSTEST 1/3] ts-debian-hvm-install: Remove VGA
console runes."):
> I don't think there is any point in these since 60b6d20b0fd2
That commit is actually c60b6d20b0fd !
> "ts-debian-hvm-install: Arrange for installed guest to use a serial
> console" and they represent
Ian Campbell writes ("[PATCH OSSTEST 2/2] cambridge: arrange to test each new
baseline"):
> Provide a new cr-daily-branch setting OSSTEST_BASELINES_ONLY which
> causes it to only attempt to test the current baseline (if it is
> untested) and never the tip version. Such tests will not result in any
Ian Campbell writes ("[PATCH OSSTEST 1/2] cr-daily-branch: Begin to support
other reasons for forcing a baseline."):
> By converting the current boolean $force_baseline into a keyword
> indicating the reason.
Acked-by: Ian Jackson
But I won't push this with my current batch.
Ian.
Ian Campbell writes ("[PATCH OSSTEST v2] No longer export $OSSTEST_CONFIG"):
> >From cri-args-hostlists or invoke-daemon.
>
> All sites now have a suitable $HOME/.xen-osstest/settings in place
> which does this.
>
> Signed-off-by: Ian Campbell
> ---
> This was waiting to be applied once " allow
Ian Campbell writes ("[PATCH OSSTEST 2/3] ts-debian-hvm-install:
di_installcmdline_core"):
> This is primarily to get DEBIAN_FRONTEND=test, for easier to read
> logging.
...
> sub grub_cfg () {
> +my @dicmdline = ();
> +my $gconsole = "console=ttyS0,115200n8";
> +
> +push @dicmdline,
On 07/24/2015 12:48 PM, Juergen Gross wrote:
On 07/24/2015 06:40 PM, Boris Ostrovsky wrote:
On 07/24/2015 12:10 PM, Juergen Gross wrote:
If we can fiddle with the masks on boot, we could do it in a running
system, too. Another advantage with not relying on cpuid. :-)
I am trying to catch up
Hi Wei,
Thanks for your reply. Sorry I did not change the comment properly.
These are the two methods I tried separately.
First method:
I see /dev/hvc1 and /dev/hvc2 being created when I give two
channels in the guest xl config file. So I wrote a program to open
hvc1 and read like below.
f
El 24/07/15 a les 17.49, Jan Beulich ha escrit:
On 24.07.15 at 17:26, wrote:
>> El 24/07/15 a les 14.44, Jan Beulich ha escrit:
>> On 24.07.15 at 14:11, wrote:
Or your idea was to put all the bitness specific registers inside of
another separate structure and then unionize them
On 07/24/2015 06:40 PM, Boris Ostrovsky wrote:
On 07/24/2015 12:10 PM, Juergen Gross wrote:
If we can fiddle with the masks on boot, we could do it in a running
system, too. Another advantage with not relying on cpuid. :-)
I am trying to catch up with this thread so I may have missed it, but
On 07/24/2015 12:39 PM, Juergen Gross wrote:
I don't say mangling cpuids can't solve the scheduling problem. It
surely can. But it can't solve the scheduling problem without hiding
information like number of sockets or cores which might be required
for license purposes. If we don't care, fine.
On 07/24/2015 12:10 PM, Juergen Gross wrote:
If we can fiddle with the masks on boot, we could do it in a running
system, too. Another advantage with not relying on cpuid. :-)
I am trying to catch up with this thread so I may have missed it, but I
still don't understand why we don't want to
On 07/24/2015 06:29 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jul 24, 2015 at 06:18:56PM +0200, Juergen Gross wrote:
On 07/24/2015 06:09 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jul 24, 2015 at 05:58:29PM +0200, Dario Faggioli wrote:
On Fri, 2015-07-24 at 17:24 +0200, Juergen Gross wrote:
On 0
Ian Campbell writes ("[PATCH OSSTEST v2] Arrange to test migration from the
previous Xen version"):
> There are several steps to this:
>
> - Identify $prevxenbranch, that is the branch which precedes
> $xenbranch.
> - Create appropriate build jobs.
> - Add support in ts-xen-install for overridi
On Fri, Jul 24, 2015 at 06:18:56PM +0200, Juergen Gross wrote:
> On 07/24/2015 06:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jul 24, 2015 at 05:58:29PM +0200, Dario Faggioli wrote:
> >>On Fri, 2015-07-24 at 17:24 +0200, Juergen Gross wrote:
> >>>On 07/24/2015 05:14 PM, Juergen Gross wrote:
> >>
Ian Campbell writes ("[PATCH OSSTEST] Match $branch against xen-* instead of
xen*"):
> In case someone invents a tree `xenblargle'.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
There are several steps to this:
- Identify $prevxenbranch, that is the branch which precedes
$xenbranch.
- Create appropriate build jobs.
- Add support in ts-xen-install for overriding {xen,}buildjob on a
per-ident basis
- Add a new receipt test-pair-oneway which only migrates from
src_host
On Mon, Jul 20, 2015 at 04:28:56PM +0200, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper
Don't you use it in:
/* Switch to low-memory stack. */
193 mov sym_phys(trampoline_phys),%edi
194 lea
In case someone invents a tree `xenblargle'.
Signed-off-by: Ian Campbell
---
ap-print-url | 2 +-
cri-common | 2 +-
mfi-common | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/ap-print-url b/ap-print-url
index 3db2375..c161169 100755
--- a/ap-print-url
+++ b/ap-print-u
On 07/24/2015 06:09 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jul 24, 2015 at 05:58:29PM +0200, Dario Faggioli wrote:
On Fri, 2015-07-24 at 17:24 +0200, Juergen Gross wrote:
On 07/24/2015 05:14 PM, Juergen Gross wrote:
On 07/24/2015 04:44 PM, Dario Faggioli wrote:
In fact, I think that it is
On Fri, 2015-07-24 at 12:09 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 24, 2015 at 05:58:29PM +0200, Dario Faggioli wrote:
> > So, just to check if I'm understanding is correct: you'd like to add an
> > abstraction layer, in Linux, like in generic (or, perhaps, scheduling)
> > code, to hide
>>> On 24.07.15 at 18:09, wrote:
> On Fri, 2015-07-24 at 09:54 -0600, Jan Beulich wrote:
>> considering the feature freeze you probably should be a little
>> more patient (e.g. ping when the development tree re-opened).
>
> I don't think all 4.7 development needs to come to a halt just because we
On 07/24/2015 05:58 PM, Dario Faggioli wrote:
On Fri, 2015-07-24 at 17:24 +0200, Juergen Gross wrote:
On 07/24/2015 05:14 PM, Juergen Gross wrote:
On 07/24/2015 04:44 PM, Dario Faggioli wrote:
In fact, I think that it is the topology, i.e., what comes from MSRs,
that needs to adapt, and foll
On Fri, Jul 24, 2015 at 05:58:29PM +0200, Dario Faggioli wrote:
> On Fri, 2015-07-24 at 17:24 +0200, Juergen Gross wrote:
> > On 07/24/2015 05:14 PM, Juergen Gross wrote:
> > > On 07/24/2015 04:44 PM, Dario Faggioli wrote:
>
> > >> In fact, I think that it is the topology, i.e., what comes from MS
On Fri, 2015-07-24 at 09:54 -0600, Jan Beulich wrote:
> considering the feature freeze you probably should be a little
> more patient (e.g. ping when the development tree re-opened).
I don't think all 4.7 development needs to come to a halt just because we
have frozen for 4.6. Although 4.6 should
On Fri, Jul 24, 2015 at 10:54 AM, Jan Beulich wrote:
On 24.07.15 at 17:39, wrote:
>> I sent out a new version of our patchset (enable per-VCPU parameter
>> settings for RTDS scheduler) two weeks ago. Can I get some feedbacks
>> and comments about it? I'm waiting for these so that I can work
>From: Wei Liu [mailto:wei.l...@citrix.com]
>Sent: Friday, July 24, 2015 2:56 AM
>
>Based on the understanding that:
>
>1. George and Jan are happy with this series merged as-is.
>2. Jan will do minor adjustments to address some issues.
>3. Ravi and Ed will send out follow-up patches post-4.6 to fi
On Fri, 2015-07-24 at 17:14 +0200, Juergen Gross wrote:
> On 07/24/2015 04:44 PM, Dario Faggioli wrote:
> > Ok. And I already have a question (as I lost track of things a bit).
> > What you just said about ACPI tables is certainly true for baremetal and
> > HVM guests, but for PV? At the time I wa
On 07/23/2015 03:25 AM, Jan Beulich wrote:
On 22.07.15 at 20:10, wrote:
I don't think this is currently doable with what we have for CPUID
support in xl syntax. I am pretty sure we need to at least be able to
specify all leaf 4's indexes. And we can't.
BTW, irrespective of this particular prob
>From: Wei Liu [mailto:wei.l...@citrix.com]
>Sent: Friday, July 24, 2015 8:40 AM
>
>In ea214001 ("x86/altp2m: add altp2mhvm HVM domain parameter"), a check
>was added to ensure nestedhvm and altp2m cannot be enabled at the same
>time. That check was added in xl, but in fact it should be in libxl be
Martin Lucina writes ("[PATCH v3] xenconsole: Ensure exclusive access to
console using locks"):
> If more than one instance of xenconsole is run against the same DOMID
> then each instance will only get some data. This change ensures
> exclusive access to the console by obtaining an exclusive lock
On Fri, 2015-07-24 at 17:24 +0200, Juergen Gross wrote:
> On 07/24/2015 05:14 PM, Juergen Gross wrote:
> > On 07/24/2015 04:44 PM, Dario Faggioli wrote:
> >> In fact, I think that it is the topology, i.e., what comes from MSRs,
> >> that needs to adapt, and follow vNUMA, as much as possible. Do we
>>> On 24.07.15 at 17:39, wrote:
> I sent out a new version of our patchset (enable per-VCPU parameter
> settings for RTDS scheduler) two weeks ago. Can I get some feedbacks
> and comments about it? I'm waiting for these so that I can work out
> the next version soon.
First of all, such a ping wo
>>> On 24.07.15 at 17:26, wrote:
> El 24/07/15 a les 14.44, Jan Beulich ha escrit:
> On 24.07.15 at 14:11, wrote:
>>> Or your idea was to put all the bitness specific registers inside of
>>> another separate structure and then unionize them? AFAICT the 16 and
>>> 32bit structures are going to
Hi,
I sent out a new version of our patchset (enable per-VCPU parameter
settings for RTDS scheduler) two weeks ago. Can I get some feedbacks
and comments about it? I'm waiting for these so that I can work out
the next version soon.
Best!
Chong
--
Chong Li
Department of Computer Science and Engi
In ea214001 ("x86/altp2m: add altp2mhvm HVM domain parameter"), a
check was added to ensure nestedhvm and altp2m cannot be enabled at
the same time. That check was added in xl, but in fact it should be in
libxl because it should be the entity that decides whether
the provided configuration is valid
On Wed, Jul 22, 2015 at 12:23:46PM -0700, Andy Lutomirski wrote:
> modify_ldt has questionable locking and does not synchronize
> threads. Improve it: redesign the locking and synchronize all
> threads' LDTs using an IPI on all modifications.
>
> This will dramatically slow down modify_ldt in mul
If more than one instance of xenconsole is run against the same DOMID
then each instance will only get some data. This change ensures
exclusive access to the console by obtaining an exclusive lock on
/xenconsole..
The locking strategy used is based on
tools/libxl/libxl_internal.c:libxl__lock_domai
El 24/07/15 a les 14.41, Jan Beulich ha escrit:
On 24.07.15 at 13:49, wrote:
>> El 24/07/15 a les 13.11, Andrew Cooper ha escrit:
>>> To start straight in 64bit, you need gdtr and cs as a minimum
>>>
>>> With that in mind, room for each of the task registers, and segment
>>> selectors.
>>
>>
El 24/07/15 a les 14.44, Jan Beulich ha escrit:
On 24.07.15 at 14:11, wrote:
>> It seems kind of pointless IMHO, the reason to have the union is to be
>> able to access the registers using the native nomenclature, but if a
>> register doesn't exist in a specific bitness I don't see the point
>>> On 23.07.15 at 13:35, wrote:
> +int pi_update_irte(struct vcpu *v, struct pirq *pirq, uint8_t gvec)
More constification is possible here.
> +{
> +struct irq_desc *desc;
> +const struct msi_desc *msi_desc;
> +int remap_index;
> +int rc = 0;
> +const struct pci_dev *pci_dev
On 07/24/2015 05:14 PM, Juergen Gross wrote:
On 07/24/2015 04:44 PM, Dario Faggioli wrote:
On Fri, 2015-07-24 at 12:28 +0200, Juergen Gross wrote:
On 07/23/2015 04:07 PM, Dario Faggioli wrote:
FWIW, I was thinking that the kernel were a better place, as Juergen is
saying, while now I'm more
On 07/24/2015 04:44 PM, Dario Faggioli wrote:
On Fri, 2015-07-24 at 12:28 +0200, Juergen Gross wrote:
On 07/23/2015 04:07 PM, Dario Faggioli wrote:
FWIW, I was thinking that the kernel were a better place, as Juergen is
saying, while now I'm more convinced that tools would be more
appropriate
On Fri, 2015-07-24 at 16:47 +0200, Martin Lucina wrote:
> If more than one instance of xenconsole is run against the same DOMID
> then each instance will only get some data. This change ensures
> exclusive access to the console by obtaining an exclusive lock on
> /xenconsole..
>
> The locking stra
>>> On 23.07.15 at 13:35, wrote:
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -238,14 +238,14 @@ static void dump_iommu_info(unsigned char key)
> else
> p = &iremap_entries[i % (1 << IREMAP_ENTRY_ORDER)];
>
> -
>>> On 23.07.15 at 13:35, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1697,14 +1697,39 @@ static void vmx_deliver_posted_intr(struct vcpu *v,
> u8 vector)
> * VMEntry as it used to be.
> */
> pi_set_on(&v->arch.hvm_vmx.pi_desc);
Martin Lucina writes ("[PATCH v2] xenconsole: Ensure exclusive access to
console using locks"):
> If more than one instance of xenconsole is run against the same DOMID
> then each instance will only get some data. This change ensures
> exclusive access to the console by obtaining an exclusive lock
On Fri, 2015-07-24 at 16:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] Arrange to test migration from
> the previous Xen version"):
> > The first branch in ./mg-list-all-branches is xen-4.0-testing and hence
> > the
> > first thing supported by select_prevxenbranch is x
Ian Campbell writes ("Re: [PATCH OSSTEST] Arrange to test migration from the
previous Xen version"):
> On Fri, 2015-07-24 at 14:55 +0100, Ian Jackson wrote:
> > Maybe these patterns should be "xen-" ? In case someone invents a
> > tree `xenblargle'.
> >
> > Hrm, I see you took the example of ap-
>>> On 23.07.15 at 13:35, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2071,6 +2071,9 @@ static int init_vtd_hw(void)
> disable_intremap(drhd->iommu);
> }
>
> +if ( !iommu_intremap )
> +iommu_intpost = 0;
Ian Campbell writes ("Re: [PATCH OSSTEST] Arrange to test migration from the
previous Xen version"):
> The first branch in ./mg-list-all-branches is xen-4.0-testing and hence the
> first thing supported by select_prevxenbranch is xen-4.1-testing. So
> perhaps the following delta would be a good id
>>> On 23.07.15 at 13:35, wrote:
> This patch adds cmpxchg16b support for x86-64, so software
> can perform 128-bit atomic write/read.
>
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Feng Wu
> ---
> v4:
> - Use pointer as the parameter of __cmpxchg16b().
> - Use gcc
If more than one instance of xenconsole is run against the same DOMID
then each instance will only get some data. This change ensures
exclusive access to the console by obtaining an exclusive lock on
/xenconsole..
The locking strategy used is based on
tools/libxl/libxl_internal.c:libxl__lock_domai
On Fri, 2015-07-24 at 12:28 +0200, Juergen Gross wrote:
> On 07/23/2015 04:07 PM, Dario Faggioli wrote:
> > FWIW, I was thinking that the kernel were a better place, as Juergen is
> > saying, while now I'm more convinced that tools would be more
> > appropriate, as Boris is saying.
>
> I've colle
On Fri, 24 Jul 2015, Stefano Stabellini wrote:
> On Fri, 24 Jul 2015, Paul Durrant wrote:
> > > -Original Message-
> > > From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> > > Sent: 24 July 2015 11:56
> > > To: Paul Durrant
> > > Cc: Stefano Stabellini; xen-de...@lists.xen
>>> On 25.06.15 at 13:17, wrote:
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -192,22 +192,33 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
> uint32_t ret = 0;
> const struct processor_pminfo *pmpt;
> struct cpufreq_policy *policy;
> +st
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: 24 July 2015 15:11
> To: Stefano Stabellini
> Cc: Paul Durrant; Stefano Stabellini; xen-de...@lists.xensource.com; Wei Liu;
> Ian Jackson; Ian Campbell
> Subject: RE: [Xen-devel] [PATCH v5 1/6]
On Fri, 2015-07-24 at 14:55 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] Arrange to test migration from the
> previous Xen version"):
> > There are several steps to this:
>
> Thanks. Much of this is very elegant.
Thank you, the building blocks are very flexible!
> > +selec
On Fri, 2015-07-24 at 14:25 +0100, Ian Campbell wrote:
>
> +branch_wants_migrupgrade_tests () {
> + case "$branch" in
> +xen*) return 0;;
> +*) return 1 ;;
> + esac
> +}
The first branch in ./mg-list-all-branches is xen-4.0-testing and hence the
first thing supported by select_prevxenbr
>>> On 25.06.15 at 13:17, 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 P-sta
>>> On 25.06.15 at 13:16, 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().
Just to continue from where I finished on the previous patch: This
is an acceptable change if the goal
Ian Campbell writes ("[PATCH OSSTEST] Arrange to test migration from the
previous Xen version"):
> There are several steps to this:
Thanks. Much of this is very elegant.
> +select_prevxenbranch () {
> + local b
> + local p
> + for b in $(./mg-list-all-branches) ; do # already sorted
On Fri, 2015-07-24 at 15:40 +0200, Martin Lucina wrote:
> On Friday, 24.07.2015 at 14:11, Ian Campbell wrote:
> > I'm afraid this (delving into another components private headers) isn't
> > allowed. Instead you should add the two lines to tools/console/Makefile
> > to generate a local _paths.h:
> >
>>> On 25.06.15 at 13:16, wrote:
> +int __init intel_pstate_init(void)
> +{
> + int cpu, rc = 0;
> + const struct x86_cpu_id *id;
> + struct cpu_defaults *cpu_info;
> +
> + id = x86_match_cpu(intel_pstate_cpu_ids);
> + if (!id)
> + return -ENODEV;
> +
> + cpu_in
On Fri, 2015-07-24 at 14:42 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] standalone: Extend -h to support
> ident=host style specifications"):
> > Allowing for multi-host tests.
> ...
> > job=$1; shift
> > - ./cs-adjust-flight -v $flight runvar-del $job host
> > + ./cs
On Fri, 2015-07-24 at 14:39 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] ts-debian-install: Stop nbd-server
> before creating the guest"):
> > Like the umount this is useful when running the test/job repeatedly in
> > development, since it allows the LV to be destroyed.
>
> T
flight 59835 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 11 guest-saverestore fail REGR.
vs. 58880
T
On Fri, 2015-07-24 at 14:32 +0100, Ian Jackson wrote:
>
>
> > +static void console_lock(int domid)
> > +{
> > + lockfile = malloc(PATH_MAX);
> > + if (lockfile == NULL)
> > + err(ENOMEM, "malloc");
> > + snprintf(lockfile, PATH_MAX - 1, "%s/xenconsole.%d",
> > XEN_LOCK_DIR, domid
Ian Campbell writes ("[PATCH OSSTEST] standalone: Extend -h to support
ident=host style specifications"):
> Allowing for multi-host tests.
...
> job=$1; shift
> - ./cs-adjust-flight -v $flight runvar-del $job host
> + ./cs-adjust-flight -v $flight runvar-del $job '/host$'
This regex
On Friday, 24.07.2015 at 14:32, Ian Jackson wrote:
> > +static void console_lock(int domid)
> > +{
> > + lockfile = malloc(PATH_MAX);
> > + if (lockfile == NULL)
> > + err(ENOMEM, "malloc");
> > + snprintf(lockfile, PATH_MAX - 1, "%s/xenconsole.%d", XEN_LOCK_DIR,
> > domid);
>
> W
On Friday, 24.07.2015 at 14:11, Ian Campbell wrote:
> I'm afraid this (delving into another components private headers) isn't
> allowed. Instead you should add the two lines to tools/console/Makefile
> to generate a local _paths.h:
>
> genpath-target = $(call buildmakevars2header,_paths.h)
> $(eva
>>> On 25.06.15 at 13:16, wrote:
> Register the CPU hotplug notifier when the driver is
> registered, and move the driver register function to
> the cpufreq.c.
At the very least this ought to be merged with the previous patch.
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpu
1 - 100 of 226 matches
Mail list logo
