>> /*
>> * Local variables:
>> * mode: C
>> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
>> index 66be53a..cdb786c 100644
>> --- a/xen/include/asm-arm/gic-its.h
>> +++ b/xen/include/asm-arm/gic-its.h
>> @@ -21,6 +21,8 @@
>> #include
>> #include
>>
>> +#define
On Tue, Jul 28, 2015 at 10:43 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> new file mode 100644
>> index 000..60f8332
>> --- /dev/null
>> +++ b/xen/arch/arm/vgic-v3-its.c
>> +
On Fri, 2015-07-31 at 05:01 +, osstest service owner wrote:
> flight 60149 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/60149/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-libvirt
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl
test guest-saverestore
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable
On Thu, Jul 30, 2015 at 3:50 PM, Andrew Cooper
wrote:
> On 30/07/2015 22:31, Andy Lutomirski wrote:
>> Note to -stable maintainers: by itself, this patch makes a
>> pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest,
>> the new ldt_gdt selftest is likely to OOPS. Even without this
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, July 24, 2015 5:41 PM
>
> ... and its callers.
>
> While all non-nested users are made fully honor the semantics of that
> type, doing so in the nested case seemed insane (if doable at all,
> considering VMCS shadowing), and hence the
On 2015/7/31 2:31, Julien Grall wrote:
> Hi,
>
> On 30/07/15 19:02, Parth Dixit wrote:
>> instead of getting mmio information for individual
>> devices from dsdt, we will map all the non-ram regions described in
>> uefi. AML interpreter option was discussed earlier and it was
> From: Ting-Wei Lan [mailto:lant...@gmail.com]
> Sent: Sunday, July 26, 2015 12:58 AM
>
> When using Linux >= 3.19 (commit 47591df) as dom0 on some Intel Ironlake
> devices, It is possible to encounter graphics issues that make screen
> unreadable or crash the system. It was reported in freedeskt
On 2015/7/31 2:02, Parth Dixit wrote:
> Hi Shannon,
> instead of getting mmio information for individual
> devices from dsdt, we will map all the non-ram regions described in
> uefi.
Yes, I don't want to use AML interpreter either. But how to get all the
non-ram regions?
> A
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, July 30, 2015 6:07 PM
> To: Hao, Xudong
> Cc: Wei Liu; xen-devel@lists.xen.org; Wu, Feng; George Dunlap
> Subject: Re: [Xen-devel] HVM guest max memory allocation
>
> On Thu, Jul 30, 2015 at 06:21:06AM +000
On 30/07/2015 22:31, Andy Lutomirski wrote:
> Note to -stable maintainers: by itself, this patch makes a
> pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest,
> the new ldt_gdt selftest is likely to OOPS. Even without this
> patch, the test can OOPS, but it's much less likely to ha
On 30/07/2015 22:32, Doug Goldstein wrote:
> On Tue, Jul 28, 2015 at 4:22 PM, Konrad Rzeszutek Wilk
> wrote:
>> On Tue, Jul 28, 2015 at 11:27:57AM -0500, Doug Goldstein wrote:
>>> On Tue, Jul 28, 2015 at 10:01 AM, Konrad Rzeszutek Wilk
>>> wrote:
On Tue, Jul 28, 2015 at 09:30:59AM -0500, Dou
On Tue, Jul 28, 2015 at 4:22 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jul 28, 2015 at 11:27:57AM -0500, Doug Goldstein wrote:
>> On Tue, Jul 28, 2015 at 10:01 AM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Tue, Jul 28, 2015 at 09:30:59AM -0500, Doug Goldstein wrote:
>> >> On Mon, Jul 27, 2015 at 4
The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace. Make it optional.
Reviewed-by: Kees Cook
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig | 17 +
arch/x86/include/asm/mmu.h | 2 ++
arch/x86/include/asm
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.
Reviewed-by: Kees Cook
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86
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
This is intended for x86/urgent. Sorry for taking so long, but it
seemed nice to avoid breaking Xen.
This fixes the "dazed and confused" issue which was exposed by the
CVE-2015-5157 fix. It's also probably a good general attack surface
reduction, and it replaces some scary code with IMO less sca
The update_va_mapping hypercall can fail if the VA isn't present in
the guest's page tables. Under certain loads, this can result in an
OOPS when the target address is in unpopulated vmap space.
While we're at it, add comments to help explain what's going on.
This isn't a great long-term fix. T
On 07/30/2015 04:05 PM, Andy Lutomirski wrote:
On Thu, Jul 30, 2015 at 1:01 PM, Boris Ostrovsky
wrote:
On 07/30/2015 02:54 PM, Andrew Cooper wrote:
On 30/07/15 19:30, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
wrote:
On 30/07/2015 00:13, Andy Lutomirski wrote:
On
On Thu, Jul 30, 2015 at 1:01 PM, Boris Ostrovsky
wrote:
> On 07/30/2015 02:54 PM, Andrew Cooper wrote:
>>
>> On 30/07/15 19:30, Andy Lutomirski wrote:
>>>
>>> On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
>>> wrote:
On 30/07/2015 00:13, Andy Lutomirski wrote:
>
> On Wed, Jul 29
On 31 July 2015 at 00:01, Julien Grall wrote:
> Hi,
>
> On 30/07/15 19:02, Parth Dixit wrote:
>> instead of getting mmio information for individual
>> devices from dsdt, we will map all the non-ram regions described in
>> uefi. AML interpreter option was discussed earlier and i
On 07/30/2015 02:54 PM, Andrew Cooper wrote:
On 30/07/15 19:30, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
wrote:
On 30/07/2015 00:13, Andy Lutomirski wrote:
On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
wrote:
On 29/07/2015 23:49, Boris Ostrovsky wrote:
On 07/2
On Thu, Jul 30, 2015 at 11:35 AM, Boris Ostrovsky
wrote:
> On 07/30/2015 02:14 PM, Andy Lutomirski wrote:
>>
>> On Thu, Jul 30, 2015 at 10:56 AM, Boris Ostrovsky
>> wrote:
>>>
>>> On 07/28/2015 01:29 AM, Andy Lutomirski wrote:
>>>
+
+static inline void load_mm_ldt(struct mm_struct *mm)
On 30/07/15 19:30, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
> wrote:
>> On 30/07/2015 00:13, Andy Lutomirski wrote:
>>> On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
>>> wrote:
On 29/07/2015 23:49, Boris Ostrovsky wrote:
> On 07/29/2015 06:46 PM, David Vra
On 07/30/2015 02:14 PM, Andy Lutomirski wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Boris Ostrovsky
wrote:
On 07/28/2015 01:29 AM, Andy Lutomirski wrote:
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+ struct ldt_struct *ldt;
+ DEBUG_LOCKS_WARN_ON(!irqs_disabled());
I
Hi,
On 30/07/15 19:02, Parth Dixit wrote:
> instead of getting mmio information for individual
> devices from dsdt, we will map all the non-ram regions described in
> uefi. AML interpreter option was discussed earlier and it was decided
> not to go with that approach. You can f
On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
wrote:
> On 30/07/2015 00:13, Andy Lutomirski wrote:
>> On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
>> wrote:
>>> On 29/07/2015 23:49, Boris Ostrovsky wrote:
On 07/29/2015 06:46 PM, David Vrabel wrote:
> On 29/07/2015 23:11, Andrew Cooper
On Thu, 2015-07-30 at 02:04 +, Wu, Feng wrote:
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -1550,9 +1550,19 @@ void context_switch(struct vcpu *prev, struct
> > vcpu *nex
於 四，2015-07-30 於 16:01 +0100，Ian Campbell 提到：
> On Thu, 2015-07-30 at 11:30 +0100, Wei Liu wrote:
> > On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote:
> > > On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote:
> > > > When --with-system-qemu is used, it is possible that we cannot fin
On Thu, Jul 30, 2015 at 10:56 AM, Boris Ostrovsky
wrote:
> On 07/28/2015 01:29 AM, Andy Lutomirski wrote:
>
>> +
>> +static inline void load_mm_ldt(struct mm_struct *mm)
>> +{
>> + struct ldt_struct *ldt;
>> + DEBUG_LOCKS_WARN_ON(!irqs_disabled());
>
>
>
> I thought this was supposed t
Hi Shannon,
instead of getting mmio information for individual
devices from dsdt, we will map all the non-ram regions described in
uefi. AML interpreter option was discussed earlier and it was decided
not to go with that approach. You can find more details in the linaro
xen wiki
On Thu, 2015-07-30 at 17:11 +0100, Wei Liu wrote:
> Update xl manual and disable PV vNUMA in libxl.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Dario Faggioli
>
> v2: improve doc and code comment.
> ---
>
Reviewed-by: Dario Faggioli
[With] Regard_s_, :-D :-
On 07/28/2015 01:29 AM, Andy Lutomirski wrote:
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+ struct ldt_struct *ldt;
+ DEBUG_LOCKS_WARN_ON(!irqs_disabled());
I thought this was supposed to be checking preemptible()?
-boris
_
On 29/07/15 12:54, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.6 6/8] tools/libxl: Prepare to write
> multiple records with EMULATOR headers"):
>> With the newly specified EMULATOR_XENSTORE_DATA record, there are two
>> libxl records with an emulator subheader. Refactor the existing
On 29/07/15 12:49, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.6 5/8] tools/libxl: Save and restore
> EMULATOR_XENSTORE_DATA content"):
>> The new EMULATOR_XENSTORE_DATA content is a sequence of NUL terminated
>> key/value strings, with the key relative to the device model's xenstore
On 07/30/2015 01:06 PM, Andrew Cooper wrote:
On 30/07/15 17:31, Boris Ostrovsky wrote:
On 07/30/2015 12:12 PM, Andrew Cooper wrote:
On 30/07/15 17:05, Borislav Petkov wrote:
On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
As far as Xen guests are concerned,
Tested-by: Boris
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 subsequent
set_phys_to_machine() will need to allocate n
Hi Vijay,
On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index a9a5874..f80f291 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -359,12 +359,14 @@ struct gic_hw_operations {
> int (*second
On 30/07/15 17:31, Boris Ostrovsky wrote:
> On 07/30/2015 12:12 PM, Andrew Cooper wrote:
>> On 30/07/15 17:05, Borislav Petkov wrote:
>>> On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
As far as Xen guests are concerned,
Tested-by: Boris Ostrovsky
>>> Does that mea
Hi Vijay,
On 27/07/15 12:11, vijay.kil...@gmail.com wrote:
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
[..]
> +static int gicv3_dist_supports_lpis(void)
> +{
> +return readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_LPIS_SUPPORTED;
> +}
> +
> static int __cpuinit gicv3_cpu_in
Instead of placing hotplugged memory at the end of RAM (which may
conflict with PCI devices or reserved regions) use allocate_resource()
to get a new, suitably aligned resource that does not conflict.
Signed-off-by: David Vrabel
Reviewed-by: Daniel Kiper
---
v3:
- Remove stale comment.
---
driv
During setup, discard RAM regions that are above the maximum
reservation (instead of marking them as E820_UNUSABLE). This allows
hotplug memory to be placed at these addresses.
Signed-off-by: David Vrabel
Reviewed-by: Daniel Kiper
---
arch/x86/xen/setup.c | 6 --
1 file changed, 4 insertio
All users of alloc_xenballoon_pages() wanted low memory pages, so
remove the option for high memory.
Signed-off-by: David Vrabel
Reviewed-by: Daniel Kiper
---
arch/x86/xen/grant-table.c | 2 +-
drivers/xen/balloon.c | 21 -
drivers/xen/grant-table.c
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 further allocations.
Signed-off-by: David Vrabel
---
v3:
- Make xen_a
Add add_memory_resource() to add memory using an existing "System RAM"
resource. This is useful if the memory region is being located by
finding a free resource slot with allocate_resource().
Xen guests will make use of this in their balloon driver to hotplug
arbitrary amounts of memory in respon
The series improves the use of hotplug memory in the Xen balloon
driver.
- Reliably find a non-conflicting location for the hotplugged memory
(this fixes memory hotplug in a number of cases, particularly in
dom0).
- Use hotplugged memory for alloc_xenballooned_pages() (keeping more
memory a
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 reduces
fragmentation in the p2m.
This is only enabled if the xen.balloon.h
Now that we track the total number of pages (included hotplugged
regions), it is easy to determine if more memory needs to be
hotplugged.
Add a new BP_WAIT state to signal that the balloon process needs to
wait until kicked by the memory add notifier (when the new section is
onlined by userspace).
Commit 0bb599fd30108883b00c7d4a226eeb49111e6932 (xen: remove scratch
frames for ballooned pages and m2p override) removed the use of the
scratch page for ballooned out pages.
Remove some left over function definitions.
Signed-off-by: David Vrabel
Reviewed-by: Daniel Kiper
---
include/xen/ballo
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 regions (note that this includes not yet onlined pages).
This will be used
On 30/07/15 17:23, Aravind Gopalakrishnan wrote:
> Some of older[Fam10h] systems require that the microcode versions
> that it comes up with should not be updated by the microcode driver.
> Otherwise, system hangs are known to occur.
>
> In this patch, we check for those microcode versions and abor
Thanks for the work on this. I had some comments and questions on the
latest draft.
On Mon, Jul 27, 2015, Konrad Rzeszutek Wilk wrote:
> +#define XSPLICE_HOWTO_FLAG_PC_REL0x1 /* Is PC relative. */
> +#define XSPLICE_HOWOT_FLAG_SIGN 0x2 /* Should the new value be treated
> as signed va
On 07/30/2015 12:23 PM, Aravind Gopalakrishnan wrote:
Some of older[Fam10h] systems require that the microcode versions
that it comes up with should not be updated by the microcode driver.
Otherwise, system hangs are known to occur.
In this patch, we check for those microcode versions and abort
On 29/07/15 10:35, David Vrabel wrote:
>
>> +EMULATOR\_XENSTORE\_DATA
>> +
>>
>> -A record containing xenstore key/value pairs of data.
>> +A set of xenstore key/value pairs for a specific emulator associated with
>> the
>> +domain.
>>
>> 0 1 2 3 4
On 29/07/15 12:28, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.6 4/8] docs/libxl: Re-specify
> XENSTORE_DATA as EMULATOR_XENSTORE_DATA"):
>> The legacy "toolstack" record as implemented in libxl turns out not to
>> be 32/64bit safe. As migration v2 has not shipped yet, take this
>> o
On 07/30/2015 12:12 PM, Andrew Cooper wrote:
On 30/07/15 17:05, Borislav Petkov wrote:
On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
As far as Xen guests are concerned,
Tested-by: Boris Ostrovsky
Does that mean, this patch 1/4 fixes the 32bit issue you guys are still
debug
Some of older[Fam10h] systems require that the microcode versions
that it comes up with should not be updated by the microcode driver.
Otherwise, system hangs are known to occur.
In this patch, we check for those microcode versions and abort the
update process if existing microcode level is alread
On 30/07/15 17:05, Borislav Petkov wrote:
> On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
>> As far as Xen guests are concerned,
>>
>> Tested-by: Boris Ostrovsky
> Does that mean, this patch 1/4 fixes the 32bit issue you guys are still
> debugging on the v4 thread? Or does that
Update xl manual and disable PV vNUMA in libxl.
Signed-off-by: Wei Liu
---
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
v2: improve doc and code comment.
---
docs/man/xl.cfg.pod.5 | 3 +++
tools/libxl/libxl_create.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/d
On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
> As far as Xen guests are concerned,
>
> Tested-by: Boris Ostrovsky
Does that mean, this patch 1/4 fixes the 32bit issue you guys are still
debugging on the v4 thread? Or does that need more fixing?
--
Regards/Gruss,
Boris.
flight 60108 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60108/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are failing
On 30/07/15 16:45, Wei Liu wrote:
> On Thu, Jul 30, 2015 at 05:30:58PM +0200, Roger Pau Monné wrote:
>> El 30/07/15 a les 17.12, Wei Liu ha escrit:
>>> Update xl manual and disable PV vNUMA in libxl.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> Cc: Ian Campbell
>>> Cc: Ian Jackson
>>> Cc: Dario Fa
On 07/28/2015 01:29 AM, Andy Lutomirski wrote:
This is intended for x86/urgent. Sorry for taking so long, but it
seemed nice to avoid breaking Xen.
This fixes the "dazed and confused" issue which was exposed by the
CVE-2015-5157 fix. It's also probably a good general attack surface
reduction,
On Thu, Jul 30, 2015 at 05:10:10PM +0200, Roger Pau Monné wrote:
> El 30/07/15 a les 17.04, Wei Liu ha escrit:
> > Hi all
> >
> > Here are some bugs that I'm aware of. The name after a item is the
> > person who is working on it.
> >
> > # Blockers
> >
> > 1. Toolstack record breaks migration v2
On Thu, Jul 30, 2015 at 05:30:58PM +0200, Roger Pau Monné wrote:
> El 30/07/15 a les 17.12, Wei Liu ha escrit:
> > Update xl manual and disable PV vNUMA in libxl.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Cc: Ian Campbell
> > Cc: Ian Jackson
> > Cc: Dario Faggioli
> > ---
> > docs/man/xl.cfg
On Thu, Jul 30, 2015 at 6:35 AM, Ian Campbell wrote:
> On Thu, 2015-07-30 at 12:23 +0100, Anthony PERARD wrote:
>> On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote:
>> > On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote:
>> > > When --with-system-qemu is used, it is possible that w
El 30/07/15 a les 17.12, Wei Liu ha escrit:
> Update xl manual and disable PV vNUMA in libxl.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Dario Faggioli
> ---
> docs/man/xl.cfg.pod.5 | 4
> tools/libxl/libxl_create.c | 9 +
> 2 files changed,
Update xl manual and disable PV vNUMA in libxl.
Signed-off-by: Wei Liu
---
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
---
docs/man/xl.cfg.pod.5 | 4
tools/libxl/libxl_create.c | 9 +
2 files changed, 13 insertions(+)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl
Andrew Cooper writes ("Re: [Xen-devel] [RFC for-4.7] Switching to a single qemu
tree each per qemu-xen and qemu-trad"):
> And take the change to drop the other random branches in the repository
> By my observations:
>
> $ git remote show upstream
> * remote upstream
> ...
> Remote branches:
El 30/07/15 a les 17.04, Wei Liu ha escrit:
> Hi all
>
> Here are some bugs that I'm aware of. The name after a item is the
> person who is working on it.
>
> # Blockers
>
> 1. Toolstack record breaks migration v2 (Andrew Cooper)
> 2. Block hotplug scripts invoked multiple times (Roger Pau Monne
Hi all
Here are some bugs that I'm aware of. The name after a item is the
person who is working on it.
# Blockers
1. Toolstack record breaks migration v2 (Andrew Cooper)
2. Block hotplug scripts invoked multiple times (Roger Pau Monne)
# Non-blockers
1. QEMU block script doesn't work (George
On Thu, 2015-07-30 at 10:56 +0100, Wei Liu wrote:
> These are only mechanical changes and I deem this fall into
> "keep documentation up to date" category, so with my RM hat on.
>
> Release-acked-by: Wei Liu
Thanks, I also ran this by Ian J and he saw no reason not to go ahead.
So I have merged
On Thu, 2015-07-30 at 11:30 +0100, Wei Liu wrote:
> On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote:
> > On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote:
> > > When --with-system-qemu is used, it is possible that we cannot find
> > > qemu-system-i386 in LIBEXEC_BIN, which can cau
On Thu, 2015-07-30 at 16:51 +0200, Vitaly Kuznetsov wrote:
> Ian Campbell writes:
>
> > (CC-ing 2x QEMU maintainers and stable release manager)
> >
> > The separate trees are a holdover from mercurial, which didn't (at the
> > time) have a good in-repo branching model.
> >
> > I propose that Xe
Ian Campbell writes:
> (CC-ing 2x QEMU maintainers and stable release manager)
>
> The separate trees are a holdover from mercurial, which didn't (at the
> time) have a good in-repo branching model.
>
> I propose that Xen 4.6 should be the last release which uses these split
> trees and that inst
On Thu, 2015-07-30 at 15:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[RFC for-4.7] Switching to a single qemu tree each
> per qemu-xen and qemu-trad"):
> ...
> > qemu-xen-traditional:
> ...
> > XXX why do staging/* exist, and what pushes from staging to the
> > other?
> > Should
On 30/07/15 15:22, Ian Campbell wrote:
> (CC-ing 2x QEMU maintainers and stable release manager)
>
> The separate trees are a holdover from mercurial, which didn't (at the
> time) have a good in-repo branching model.
>
> I propose that Xen 4.6 should be the last release which uses these split
> tre
On Thu, 2015-07-30 at 18:21 +0530, Manish Jaggi wrote:
>
> On Thursday 30 July 2015 03:24 PM, Ian Campbell wrote:
> > On Wed, 2015-07-29 at 15:07 +0530, Manish Jaggi wrote:
> > > On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
> > > > On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
> >
Ian Campbell writes ("[RFC for-4.7] Switching to a single qemu tree each per
qemu-xen and qemu-trad"):
...
> qemu-xen-traditional:
...
> XXX why do staging/* exist, and what pushes from staging to the other?
> Should we ditch one or the other?
Once upon a time, some of these had their own
(CC-ing 2x QEMU maintainers and stable release manager)
The separate trees are a holdover from mercurial, which didn't (at the
time) have a good in-repo branching model.
I propose that Xen 4.6 should be the last release which uses these split
trees and that instead we combine them into just qemu-
This is handy to have, editing it in locally just means one cannot
simply use "crontab contab-cambridge" to load a new one without
remembering the content of the line for next time.
Signed-off-by: Ian Campbell
---
crontab-cambridge | 1 +
1 file changed, 1 insertion(+)
diff --git a/crontab-camb
ControlDaemonHost is unused in production-config* since they both set
{Owner,Queue}DaemonHost explicitly.
Some sort of default seems useful, so switch it to just
"control-daemons" in the DNS domain of the controller.
Signed-off-by: Ian Campbell
---
Osstest/Executive.pm | 2 +-
1 file changed, 1
On 07/30/2015 06:57 AM, Ian Campbell wrote:
On Wed, 2015-07-29 at 16:36 -0400, Brandon Perez wrote:
On 07/21/2015 11:12 AM, Ian Campbell wrote:
On Tue, 2015-07-21 at 10:07 -0400, Brandon Perez wrote:
I'm not sure that these patches are quite ready yet to be put
into
the Xen repo.
Tha
On 07/30/2015 07:23 AM, Ian Campbell wrote:
On Wed, 2015-07-29 at 16:36 -0400, Brandon Perez wrote:
On 07/21/2015 11:12 AM, Ian Campbell wrote:
On Tue, 2015-07-21 at 10:07 -0400, Brandon Perez wrote:
I'm not sure that these patches are quite ready yet to be put
into
the Xen repo.
Tha
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 30 July 2015 14:19
> To: Paul Durrant; Roger Pau Monne; xen-devel
> Subject: Re: [BUG] Emulation issues
>
> On 30/07/15 14:12, Paul Durrant wrote:
> >> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1.
On 30/07/15 14:12, Paul Durrant wrote:
>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1.
>> (XEN) domain_crash called from io.c:166
>> (XEN) d19v0 weird emulation state 1
>> (XEN) io.c:165:d19v0 Weird HVM ioemulation status 1.
>> (XEN) domain_crash called from io.c:166
>> (XEN) d19v0 weird em
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: 30 July 2015 14:06
> To: Paul Durrant; xen-devel; Andrew Cooper
> Subject: Re: [BUG] Emulation issues
>
> El 30/07/15 a les 12.59, Paul Durrant ha escrit:
> >> -Original Message-
> > [big snip]
> >>
El 30/07/15 a les 12.59, Paul Durrant ha escrit:
>> -Original Message-
> [big snip]
>> Sorry, missed that in the noise. So, the problem is that there is no
>> in-flight I/O
>> even though pio completion is being attempted. Something has got out of
>> sync.
>>
>
> I think I understand what
On Thursday 30 July 2015 03:24 PM, Ian Campbell wrote:
On Wed, 2015-07-29 at 15:07 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 03:50 PM, Ian Campbell wrote:
On Mon, 2015-07-06 at 15:36 +0530, Manish Jaggi wrote:
On Monday 06 July 2015 02:41 PM, Ian Campbell wrote:
On Sun, 2015-07-05 a
On 2015/7/5 21:30, Parth Dixit wrote:
> +shannon
>
> On 15 June 2015 at 06:49, Julien Grall wrote:
>> Hi Parth,
>>
>> On 14/06/2015 11:27, Parth Dixit wrote:
>>>
>>> On 8 June 2015 at 22:20, Julien Grall wrote:
Hi Parth,
On 17/05/2015 21:03, Parth Dixit wrote:
>
>
>
On 07/30/2015 12:29 PM, Lars Kurth wrote:
So far, I am aware of one talk. Note that the OpenStack summit agenda's
are determined by popular vote (which ends today).
If there are others Xen related talks, feel free to add by replying to
this mail
https://www.openstack.org/summit/tokyo-2015/vote-f
Hi Ian,
On 30/07/15 09:55, Ian Campbell wrote:
> On Wed, 2015-07-29 at 19:18 +0100, Julien Grall wrote:
>> It appears to be required on the Arndale to boot secondaries CPUs.
>> Although, depending on where I put the sev I don't have the same
>> behavior:
>> - sev in smp_init callback: the CP
On Thu, 2015-07-30 at 12:23 +0100, Anthony PERARD wrote:
> On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote:
> > On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote:
> > > When --with-system-qemu is used, it is possible that we cannot find
> > > qemu-system-i386 in LIBEXEC_BIN, which
On Wed, 2015-07-29 at 16:53 -0400, Brandon Perez wrote:
> In general, Xen needs to own very few interrupts to run. Most of these are
> timer
> PPIs, which do not involve the crossbar. The notable exception to this is the
> serial device, which is an SPI. On the DRA7 chips, this involves going thro
On 30/07/15 11:54, Stefano Stabellini wrote:
> On Thu, 30 Jul 2015, Ian Campbell wrote:
>> On Wed, 2015-07-29 at 19:18 +0100, Julien Grall wrote:
>>
>> As an aside from the issue you are seeing:
>>
>>> The old implementation of spinlock is sending an event (via the assembly
>>> instruction SEV) to
On Thu, 2015-07-30 at 11:54 +0100, Stefano Stabellini wrote:
> On Thu, 30 Jul 2015, Ian Campbell wrote:
> > On Wed, 2015-07-29 at 19:18 +0100, Julien Grall wrote:
> >
> > As an aside from the issue you are seeing:
> >
> > > The old implementation of spinlock is sending an event (via the
> > > as
On Thu, 30 Jul 2015, Juan Quintela wrote:
> Anthony PERARD wrote:
> > This is a critical issue for Xen as migration either with the same version
> > of QEMU, or from a previous version of QEMU is broken.
> >
> > Any suggestion on how to move forward?
>
> Will send a pull requset tomorrow.
>
> Th
On Thu, Jul 30, 2015 at 11:24:47AM +0100, Ian Campbell wrote:
> On Thu, 2015-07-30 at 14:51 +0800, Ting-Wei Lan wrote:
> > When --with-system-qemu is used, it is possible that we cannot find
> > qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons
> > init script and xen-qemu-dom0-d
On Wed, 2015-07-29 at 16:36 -0400, Brandon Perez wrote:
> On 07/21/2015 11:12 AM, Ian Campbell wrote:
> > On Tue, 2015-07-21 at 10:07 -0400, Brandon Perez wrote:
> > >
> > > I'm not sure that these patches are quite ready yet to be put
> > > into
> > > the Xen repo.
> >
> > That's ok, but e
On Wed, 2015-07-29 at 16:53 -0400, Brandon Perez wrote:
> Originally, Xen did not allow for guests to make SMC calls. However, on the
> DRA7
> chips, the kernel needs to make several SMC calls to interact with the secure
> ROM code.
>
> There are two solutions for solving this in the patch. The s
1 - 100 of 134 matches
Mail list logo
