On Sat, 2015-05-23 at 14:46 +0800, Robert Hu wrote:
> On Sat, 2015-05-23 at 11:35 +0800, Robert Hu wrote:
> > On Fri, 2015-05-22 at 15:21 +0100, Ian Campbell wrote:
> > > On Fri, 2015-05-22 at 14:42 +0100, Ian Campbell wrote:
> > > > From my particular grub.cfg. For real usage setupboot_grub2 will
On Sat, 2015-05-23 at 11:35 +0800, Robert Hu wrote:
> On Fri, 2015-05-22 at 15:21 +0100, Ian Campbell wrote:
> > On Fri, 2015-05-22 at 14:42 +0100, Ian Campbell wrote:
> > > From my particular grub.cfg. For real usage setupboot_grub2 will
> > > obviously need to become cleverer to count things corr
flight 57033 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57033/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
Hi Dario,
2015-05-22 3:19 GMT-07:00 Dario Faggioli :
>
> [ Adding to Cc the people that I though I added when sending the patch,
> but that apparently I haven't...sorry :-( ]
Thanks for cc.ing us. :-)
>
> On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote:
> > the SEDF scheduler is about
On Fri, 2015-05-22 at 15:21 +0100, Ian Campbell wrote:
> On Fri, 2015-05-22 at 14:42 +0100, Ian Campbell wrote:
> > From my particular grub.cfg. For real usage setupboot_grub2 will
> > obviously need to become cleverer to count things correctly.
>
> I've not tested extensively but the following in
flight 56979 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56979/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
On 05/22/2015 04:11 AM, Sander Eikelenboom wrote:
Hello Sander,
Friday, May 15, 2015, 12:47:27 AM, you wrote:
Sorry for the resend, i messed up the to's en from's.
Hi Konrad / David,
One big snip on this thread, got some more debug info, hopefully this will
lead to something:
On a wor
From: Elena Ufimtseva
For sbdf'si parsing in rmrr command line add __parse_pci with addtional
parameter def_seg. __parse_pci will help to identify if segment was found
in string being parsed or default segment was used.
Make a wrapper parse_pci so the rest of the callers are not affected.
Signed
From: Elena Ufimtseva
Signed-off-by: Elena Ufimtseva
---
xen/include/xen/pci.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 4377f3e..4ddf791 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -33,6 +33,7 @@
#define PCI_D
From: Elena Ufimtseva
In preparation for auxiliary RMRR data provided on Xen
command line, make RMRR adding a separate function.
Also free memery for rmrr device scope in error path.
Signed-off-by: Elena Ufimtseva
---
xen/drivers/passthrough/vtd/dmar.c | 130 ---
From: Elena Ufimtseva
On some platforms RMRR regions may be not specified
in ACPI and thus will not be mapped 1:1 in dom0. This
causes IO Page Faults and prevents dom0 from booting
in PVH mode.
New Xen command line option rmrr allows to specify
such devices and memory regions. These regions are a
From: Elena Ufimtseva
Add Xen command line option rmrr to specify RMRR
regions for devices that are not defined in ACPI thus
causing IO Page Fault while booting dom0 in PVH mode.
These additional regions will be added to the list of
RMRR regions parsed from ACPI.
Changes in v5:
- make parse_pci
From: Elena Ufimtseva
Release memory allocated for scope.devices when disabling
dmar units. Also set device count after memory allocation when
device scope parsing.
Signed-off-by: Elena Ufimtseva
---
xen/drivers/passthrough/vtd/dmar.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
flight 56978 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56978/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 56791
test-amd64-i386-freebsd10-amd64
flight 56974 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56974/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win
flight 56972 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56972/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never
pass
test-amd64-i386-xl-qemuu-debianhvm-amd
flight 56964 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56964/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 56791
test-amd64-i386-freebsd10-amd6
flight 56959 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56959/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 14 guest-saverestore.2fail REGR. vs. 56375
test-armhf-armhf-xl-
flight 56966 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 53854
test-amd64-i386-libvirt
Ahoy there!
I was attempting to compile Xen from branches: `master`, and `stable-4.5` I had
some trouble initially, as Ubuntu 12.04 defaults to an old version of gcc. I
updated gcc to 4.9 from the toolchain ppa, and was NOT able to compile Xen on
either branch. Installing and configuring gcc 4.
On Tue, May 12, 2015 at 5:01 AM, Dario Faggioli
wrote:
> [Adjusting the Cc list:
> - removing hypervisor only people
> - adding more tools maintainers
> - adding George]
>
> On Thu, 2015-05-07 at 12:05 -0500, Chong Li wrote:
>> Change sched_rtds_domain_get/set functions to support per-VCPU s
Am 21.05.2015 um 20:11 schrieb Ian Campbell:
> On Thu, 2015-05-21 at 17:17 +0200, Marco Steinacher wrote:
>> Shall I try to build a 3.16.0-4-686-pae kernel with
>> "CONFIG_NEED_DMA_MAP_STATE=y"?
>
> Yes, this is what I would recommend. Although it's not as simple as
> turning it on, you actually n
On 19 May 2015, at 17:36, Wei Liu wrote:
> On Tue, May 12, 2015 at 07:18:32PM +0200, Joao Martins wrote:
>> On xenvif_start_xmit() we have an additional queue to the netback RX
>> kthread that will sends the packet. When using burst>1 pktgen sets
>> skb->xmit_more to tell the driver that there m
On Fri, May 22, 2015 at 05:58:41PM +0100, David Vrabel wrote:
> On 22/05/15 17:42, Marek Marczykowski-Górecki wrote:
> > On Fri, May 22, 2015 at 05:25:44PM +0100, David Vrabel wrote:
> >> On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> >>> Hi all,
> >>>
> >>> I'm experiencing xen-netfront cr
On 22/05/15 17:42, Marek Marczykowski-Górecki wrote:
> On Fri, May 22, 2015 at 05:25:44PM +0100, David Vrabel wrote:
>> On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
>>> Hi all,
>>>
>>> I'm experiencing xen-netfront crash when doing xl network-detach while
>>> some network activity is going
On Fri, May 22, 2015 at 05:25:44PM +0100, David Vrabel wrote:
> On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> > Hi all,
> >
> > I'm experiencing xen-netfront crash when doing xl network-detach while
> > some network activity is going on at the same time. It happens only when
> > domU has
>>> On 22.05.15 at 17:36, wrote:
> On 13.05.15 at 11:49, wrote:
>>> +if ( !source_d->is_dying )
>>> +{
>>> +/*
>>> + * Make sure no allocation/remapping for the source domain is
>>> ongoing
>>> + * and set is_dying flag to prevent such actions in future.
>>> +
On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> I'm experiencing xen-netfront crash when doing xl network-detach while
> some network activity is going on at the same time. It happens only when
> domU has more than one vcpu. Not sure if this matters, but the backend
> is in anot
Changes v10 to v11:
Andrew Cooper & Ian Campbell (#1 "tools: Add vga=vmware"):
Nack. Qemu-trad is currently has remote code execution vulnerabilities.
Dropped support for Qemu-trad.
Also changed later patchs to not need this one.
Andrew Cooper (#2 "xen: Add support for VMw
This is done by adding xen_arch_domainconfig vmware_hw. It is set to
the VMware virtual hardware version.
Currently 0, 3-4, 6-11 are good values. However the
code only checks for == 0 or != 0 or >= 7.
If non-zero then
Return VMware's cpuid leaves. If >= 7 return data, else
return 0.
The su
This file: backdoor_def.h comes from:
http://packages.vmware.com/tools/esx/3.5latest/rhel4/SRPMS/index.html
open-vm-tools-kmod-7.4.8-396269.423167.src.rpm
open-vm-tools-kmod-7.4.8.tar.gz
vmhgfs/backdoor_def.h
and is unchanged.
Added the badly named include file includeCheck.h also. It onl
This is used to set xen_arch_domainconfig vmware_hw. It is set to
the emulated VMware virtual hardware version.
Currently 0, 3-4, 6-11 are good values. However the code only
checks for == 0, != 0, or < 7.
Signed-off-by: Don Slutz
---
v11:
Dropped "If non-zero then default VGA to VMware's VGA"
This includes adding is_vmware_port_enabled
This is a new xen_arch_domainconfig flag,
XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK.
This enables limited support of VMware's hyper-call.
This is both a more complete support then in currently provided by
QEMU and/or KVM and less. The missing part requires Q
Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
to port 0x5658 specially. Note: since many operations return data
in EAX, "in (%dx),%eax" is the one to use. The other lengths like
"in (%dx),%al" will still do things, only AL part of EAX will be
changed. For "out %eax,(%dx)" o
Also added missing TRAP_DEBUG & VLAPIC.
Signed-off-by: Don Slutz
Acked-by: Ian Campbell
---
v11:
No change
v10:
Added Acked-by: Ian Campbell
Added back in the trace point calls.
Why is cmd in this patch?
Because the trace points use it.
v9:
Dropped unneed VMPORT_UNHANDLED, V
This new libxl_domain_create_info field is used to set
XEN_DOMCTL_CONFIG_VMWARE_PORT_MASK in the xc_domain_configuration_t
for x86.
In xen it is is_vmware_port_enabled.
If is_vmware_port_enabled then
enable a limited support of VMware's hyper-call.
VMware's hyper-call is also known as VMware B
This adds synchronization of the 6 vcpu registers (only 32bits of
them) that vmport.c needs between Xen and QEMU.
This is to avoid a 2nd and 3rd exchange between QEMU and Xen to
fetch and put these 6 vcpu registers used by the code in vmport.c
and vmmouse.c
In the tools, enable usage of QEMU's vm
This allows use of QEMU's VMware emulated video card
NOTE: vga=vmware is not supported by device_model_version=qemu-xen-traditional
Signed-off-by: Don Slutz
---
v11:
Dropped support for Qemu-trad.
Also changed later patchs to not need this one.
v10: New at v10.
Was part of "tools: Add vm
"Jan Beulich" writes:
On 13.05.15 at 11:49, wrote:
>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -580,6 +580,234 @@ static long
>> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
>> return rc;
>> }
>>
>> +static long
>> memory_soft_reset(XEN_GU
>>> On 22.05.15 at 16:58, wrote:
> On 05/22/2015 05:40 AM, Jan Beulich wrote:
> On 13.05.15 at 11:49, wrote:
>>> --- a/xen/include/xsm/dummy.h
>>> +++ b/xen/include/xsm/dummy.h
>>> @@ -193,6 +193,13 @@ static XSM_INLINE int
> xsm_memory_exchange(XSM_DEFAULT_ARG struct domain *d)
>>> re
"Jan Beulich" writes:
On 13.05.15 at 11:49, wrote:
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -193,6 +193,13 @@ static XSM_INLINE int
>> xsm_memory_exchange(XSM_DEFAULT_ARG struct domain *d)
>> return xsm_default_action(action, current->domain, d);
>> }
>
On 05/22/2015 05:40 AM, Jan Beulich wrote:
On 13.05.15 at 11:49, wrote:
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -193,6 +193,13 @@ static XSM_INLINE int xsm_memory_exchange(XSM_DEFAULT_ARG
struct domain *d)
return xsm_default_action(action, current->domain, d);
}
Vitaly Kuznetsov writes:
> Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
> content with xc_domain_soft_reset(), reload dm and toolstack.
>
..skip..
> +void libxl__xc_domain_soft_reset(libxl__egc *egc,
> + libxl__domain_create_state *dcs)
>
On Fri, May 22, 2015 at 8:05 PM, Julien Grall wrote:
> On 22/05/15 14:58, Vijay Kilari wrote:
>> On Fri, May 22, 2015 at 6:19 PM, Julien Grall
>> wrote:
1) Command translation:
---
- ITS commands contains device ID, Event ID (vID), Collection
On Thu, 2015-05-21 at 09:45 +0100, Ian Campbell wrote:
> The bisector is still working on it at
> http://logs.test-lab.xenproject.org/osstest/results/bisect.xen-unstable.test-armhf-armhf-xl-multivcpu.leak-check--check.html
> although I'm not sure if it is actually going to produce a result.
It se
On 22/05/15 14:58, Vijay Kilari wrote:
> On Fri, May 22, 2015 at 6:19 PM, Julien Grall wrote:
>>> 1) Command translation:
>>> ---
>>>
>>> - ITS commands contains device ID, Event ID (vID), Collection ID
>>> (vCID), Target Address (vTA)
>>> parameters
>>> - All
flight 56946 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56946/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 19 guest-start/freebsd.repeat fail REGR. vs.
56831
Tests which ar
On 05/21/2015 09:18 PM, Xu, Quan wrote:
-Original Message-
From: Kevin O'Connor [mailto:ke...@koconnor.net]
Sent: Friday, May 22, 2015 1:20 AM
To: Stefan Berger
Cc: Xu, Quan; seab...@seabios.org; stefano.stabell...@eu.citrix.com;
xen-devel@lists.xen.org; Daniel De Graaf; wei.l...@citrix
On Fri, 2015-05-22 at 14:42 +0100, Ian Campbell wrote:
> From my particular grub.cfg. For real usage setupboot_grub2 will
> obviously need to become cleverer to count things correctly.
I've not tested extensively but the following incremental patch seems to
do the right thing, at least by inspecti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/22/2015 09:04 AM, Jan Beulich wrote:
> If you were to ask for this only if the time gap until embargo expiry
> was less than the default of two weeks, maybe I would buy this.
I'm good with that as well. I think we're saying:
if embargo_len
>>> On 22.05.15 at 15:14, wrote:
> My request is that the Xen security team would send a pre-disclosure notice
> of the vulnerability as soon as permission from the discoverer is granted
> *even if* patches aren't available. For example, I'd like to receive a
> notice saying "there's a vulnera
On 22/05/15 14:55, Jan Beulich wrote:
> ... resulting from fbeef5570c ("x86/cpuidle: get accurate C0 value with
> xenpm tool"). For consistency also no longer account an unknown state
> to C0 in pmstat_get_cx_stat().
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Looks plausible. R
On Fri, May 22, 2015 at 6:19 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 22/05/15 13:16, Vijay Kilari wrote:
>> On Tue, May 19, 2015 at 7:21 PM, Ian Campbell
>> wrote:
>>> On Tue, 2015-05-19 at 14:37 +0100, Julien Grall wrote:
Hi Ian,
On 19/05/15 13:10, Ian Campbell wrote:
> On
... resulting from fbeef5570c ("x86/cpuidle: get accurate C0 value with
xenpm tool"). For consistency also no longer account an unknown state
to C0 in pmstat_get_cx_stat().
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.
>>> On 22.05.15 at 14:57, wrote:
> On 22/05/15 13:48, Jan Beulich wrote:
>> ... resulting from fbeef5570c ("x86/cpuidle: get accurate C0 value with
>> xenpm tool").
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
>
> This appears to fix the issue.
>
> However, looking at the oth
On Fri, 2015-05-22 at 13:58 +0100, Ian Campbell wrote:
> On Fri, 2015-05-22 at 20:47 +0800, Robert Hu wrote:
> > On Fri, 2015-05-22 at 13:30 +0100, Ian Campbell wrote:
> > > On Fri, 2015-05-22 at 12:32 +0100, Ian Campbell wrote:
> > > > I'm currently testing the patch below, if it works then I inte
On 05/22/2015 02:40 AM, Jan Beulich wrote:
> I realize this is being written under the impression of XSA-133, where
> the usual 2 week window between pre-disclosure and public disclosure
> was (almost) missing. But that's an exception, not the rule. Are you
> saying that the usual 2 week advance no
On Fri, 2015-05-22 at 20:47 +0800, Robert Hu wrote:
> On Fri, 2015-05-22 at 13:30 +0100, Ian Campbell wrote:
> > On Fri, 2015-05-22 at 12:32 +0100, Ian Campbell wrote:
> > > I'm currently testing the patch below, if it works then I intend to fold
> > > it into "Parsing grub which has 'submenu' prim
On 22/05/15 13:48, Jan Beulich wrote:
> ... resulting from fbeef5570c ("x86/cpuidle: get accurate C0 value with
> xenpm tool").
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
This appears to fix the issue.
However, looking at the other cases which play the same games, 0 is used
in
Hi Vijay,
On 22/05/15 13:16, Vijay Kilari wrote:
> On Tue, May 19, 2015 at 7:21 PM, Ian Campbell wrote:
>> On Tue, 2015-05-19 at 14:37 +0100, Julien Grall wrote:
>>> Hi Ian,
>>>
>>> On 19/05/15 13:10, Ian Campbell wrote:
On Fri, 2015-05-15 at 15:55 +0100, Julien Grall wrote:
[...]
>
>>> On 22.05.15 at 14:45, wrote:
> On 05/22/2015 03:22 PM, Jan Beulich wrote:
> On 22.05.15 at 14:15, wrote:
>>> While working on this I found the following in the vm_event.h header:
>>>
>>> 168 struct vm_event_debug {
>>> 169 uint64_t gfn;
>>> 170 uint32_t _pad;
>>> 171 };
>>>
>>> Is
... resulting from fbeef5570c ("x86/cpuidle: get accurate C0 value with
xenpm tool").
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -279,7 +279,7 @@ static void print_acpi_power(
uint64_t usage[ACPI_PROCESSOR_
On Fri, 2015-05-22 at 13:30 +0100, Ian Campbell wrote:
> On Fri, 2015-05-22 at 12:32 +0100, Ian Campbell wrote:
> > I'm currently testing the patch below, if it works then I intend to fold
> > it into "Parsing grub which has 'submenu' primitive" and will re-push
> > the result.
>
> It didn't seem
On 05/22/2015 03:22 PM, Jan Beulich wrote:
On 22.05.15 at 14:15, wrote:
>> While working on this I found the following in the vm_event.h header:
>>
>> 168 struct vm_event_debug {
>> 169 uint64_t gfn;
>> 170 uint32_t _pad;
>> 171 };
>>
>> Is this supposed to be 64 + 32 bits padding?
>
On Fri, 2015-05-22 at 12:32 +0100, Ian Campbell wrote:
> I'm currently testing the patch below, if it works then I intend to fold
> it into "Parsing grub which has 'submenu' primitive" and will re-push
> the result.
It didn't seem to work. I'm trying to repro on a machine I can recover
more easily
Signed-off-by: Ian Campbell
---
Osstest/TestSupport.pm | 37 -
README | 1 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index da881ec..6450ee6 100644
--- a/Osstest/TestSupport.
The mechanism used to PXE boot can differ depending on the firmware
type. Therefore refactor into Osstest::TestSupport and key off a new
host property "firmware".
Currently supported is "bios" (the default) and "uboot", both of which
use pxelinux.cfg style files.
The default for the firmware prop
XXX fold somewhere?
---
ts-host-install | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-host-install b/ts-host-install
index aab5241..2dad9f1 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -258,6 +258,9 @@ END
if -e "$ho->{Tftp}{Path}/$d_i/$kp-dtbs";
}
+$xop
This is very useful when iterating over kernel configurations, since
it avoids blowing away the build tree and all the existing built
objects. The Linux build system does the right thing when .config
changes and only rebuilds the affected bits.
Signed-off-by: Ian Campbell
---
ts-kernel-build | 1
Debian inserts itself before any existing entries, including the PXE
one, meaning we otherwise cannot remotely regroove the box. Preseed
some commands to reset the boot order to BootCurrent i.e. how we
booted (so the PXE entry).
There is still a window between the Debian entry being added (by
grub
OSSTEST_CONFIG still trumps both.
Signed-off-by: Ian Campbell
---
standalone | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/standalone b/standalone
index 17fa40c..ad12bad 100755
--- a/standalone
+++ b/standalone
@@ -68,7 +68,13 @@ TEMP=$(getopt -o c:f:h:rRs --long
co
XXX We probably need a newer kernel to actually be useful.
Signed-off-by: Ian Campbell
---
ts-kernel-build | 10 ++
1 file changed, 10 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index c746584..cdef97c 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -525,6 +525,16
The story for PXE booting via UEFI (at least on arm64) is not so
straightforward as with pxelinux on x86. There seems to no good
bootloader to launch via UEFI+pxe, in fact all I could find was grub
(syslinux, and by extension pxelinux.efi, is x86 only).
Add mg-pxe-loader-update modelled on mg-debi
Runvars:
build-arm64 arch
arm64
build-arm64 build_lvextend_max
50
build-arm64 enable_ovmf
true
build-arm64
Other bootloaders handle this with an explicit separate option rather
than parsing it out of the command line as pxelinux does. Prepare for
supporting these.
Signed-off-by: Ian Campbell
---
ts-host-install | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ts-host-install
First arrange for bootloader to be installed to removable media path,
by using a new in Jessie preseed option. Then use that to chainload a
bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which
saves us having to worry about which OS is on the host (so long
(i.e. the bit before/after the -- marker). When abstracting over
different bootloaders in a future patch this will be convenient since
it allows the code to add to either.
Signed-off-by: Ian Campbell
---
ts-host-install | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-
AIUI the runes used will only result in an ESP if the system was
booted via UEFI. IOW I don't think there should be any change for
existing systems.
Signed-off-by: Ian Campbell
---
Osstest.pm| 1 +
Osstest/Debian.pm | 6 ++
2 files changed, 7 insertions(+)
diff --git a/Osstest.pm b/
The following makes a start on support for arm64 systems.
Since arm64 was only added in Debian Jessie this requires Wei's "Debian
Jessie patches" as a base line, but without the
"mg-debian-installer-update: use new url for armhf packages" patch which
is replaced here. (Wei, I cc'd you on that one)
For armhf and arm64 for Jessie we will need these in the normal case
as well as in the backports case. Arrange to download.
Signed-off-by: Ian Campbell
---
mg-debian-installer-update | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/mg-debian-installer-update b/mg
In mg-debian-installer-update:
- Expand the list of (suite,arch) combinations which don't exist and
move it to the top.
- Tweak the backports.org handling to allow it to be specified on a
per (suite,arch) basis, and specify it only for (wheezy,armhf)
since it is not currently need
On 21/05/15 10:39, Huaitong Han wrote:
> When checking the ACPI funciton of C-status, after 100 seconds sleep,
> the sampling value of C0 status from the xenpm tool decreases.
> Because C0=NOW()-C1-C2-C3-C4, when NOW() value is during idle time,
> NOW() value is bigger than last C-status update tim
>>> On 22.05.15 at 14:15, wrote:
> While working on this I found the following in the vm_event.h header:
>
> 168 struct vm_event_debug {
> 169 uint64_t gfn;
> 170 uint32_t _pad;
> 171 };
>
> Is this supposed to be 64 + 32 bits padding?
I think I need to direct the question back to you.
On Tue, May 19, 2015 at 7:21 PM, Ian Campbell wrote:
> On Tue, 2015-05-19 at 14:37 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 19/05/15 13:10, Ian Campbell wrote:
>> > On Fri, 2015-05-15 at 15:55 +0100, Julien Grall wrote:
>> > [...]
>> >>> Translation of certain commands can be expensive (XXX
On 05/22/2015 10:36 AM, Jan Beulich wrote:
>> @@ -1050,6 +1048,8 @@ struct xen_domctl_monitor_op {
>> */
>> union {
>> struct {
>> +/* Which control register */
>> +uint8_t index;
>
> Okay, 8 bits here (which is reasonable), but ...
>
>> @@ -156,7 +158,
Hi all,
I'm experiencing xen-netfront crash when doing xl network-detach while
some network activity is going on at the same time. It happens only when
domU has more than one vcpu. Not sure if this matters, but the backend
is in another domU (not dom0). I'm using Xen 4.2.2. It happens on kernel
3.
(I thought I'd hit send on this already, sorry if it is a repeat)
On Fri, 2015-05-22 at 10:17 +0100, Ian Campbell wrote:
> On Thu, 2015-05-21 at 18:05 +0100, Ian Campbell wrote:
> > Assuming this flight produces something useful (i.e. a pass) then I'll
> > look into a bisect.
>
> With this and a
On Fri, May 22, 2015 at 01:32:01PM +0200, Olaf Hering wrote:
> On Fri, May 22, Wei Liu wrote:
>
> > On Fri, May 22, 2015 at 08:19:32AM +, Olaf Hering wrote:
> > > BIN = xentrace xentrace_setsize
> > > +SBIN = xenalyze
> >
> > Why is xenalyze not placed in the same directory as xentr
On Fri, 2015-05-22 at 10:57 +0100, Ian Campbell wrote:
> Hi Robert and Longtao,
>
> On Fri, 2015-05-22 at 02:08 +, osstest service user wrote:
> > flight 56922 osstest real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/56922/
> >
> > Regressions :-(
>
> This flight was testing:
On Fri, May 22, Wei Liu wrote:
> On Fri, May 22, 2015 at 08:19:32AM +, Olaf Hering wrote:
> > BIN = xentrace xentrace_setsize
> > +SBIN = xenalyze
>
> Why is xenalyze not placed in the same directory as xentrace? My
> impression is that they are closely related. What did I miss?
>
On Fri, May 22, 2015 at 08:19:32AM +, Olaf Hering wrote:
> This merges xenalyze.hg, changeset 150:24308507be1d,
> into tools/xentrace/xenalyze.c to have the tool and
> public/trace.h in one place.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
Enabling posted interrupts requires the virtual interrupt delivery feature,
which is disabled for PVH guests, so make sure posted interrupts are also
disabled or else vmlaunch will fail.
Signed-off-by: Roger Pau Monné
Reported-and-Tested-by: Lars Eggert
Acked-by: Kevin Tian
Cc: Jun Nakajima
Cc
On Fri, May 22, 2015 at 08:19:37AM +, Olaf Hering wrote:
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists
On Fri, May 22, 2015 at 08:19:39AM +, Olaf Hering wrote:
> Since xenalyze is now upstream its Open Source and part of the given
> release.
>
> Signed-off-by: Olaf Hering
> Acked-by: George Dunlap
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
Acked-by: Wei L
flight 56941 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728
Tests which are f
Hi,
On 22/05/2015 10:35, Tiejun Chen wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 0c0ea4a..203c80e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -499,6 +499,11 @@ struct xen_domctl_assign_device {
XEN_GUEST_HAND
On 19 May 2015, at 17:39, Wei Liu wrote:
> On Tue, May 12, 2015 at 07:18:24PM +0200, Joao Martins wrote:
>
>> There have been recently[3] some discussions and issues raised on
>> persistent grants for the block layer, though the numbers above
>> show some significant improvements specially on m
On 19 May 2015, at 17:35, Wei Liu wrote:
> On Tue, May 12, 2015 at 07:18:30PM +0200, Joao Martins wrote:
>> By introducing persistent grants we speed up the RX thread with the
>> decreased copy cost, that leads to a throughput decrease of 20%.
>> It is observed that the rx_queue stays mostly at
On 19 May 2015, at 17:23, Wei Liu wrote:
> On Tue, May 12, 2015 at 07:18:27PM +0200, Joao Martins wrote:
>> Introduces persistent grants for TX path which follows similar code path
>> as the grant mapping.
>>
>> It starts by checking if there's a persistent grant available for header
>> and frag
Hi,
On 22/05/2015 10:35, Tiejun Chen wrote:
Here we'll construct a basic guest e820 table via
XENMEM_set_memory_map. This table includes lowmem, highmem
and RDMs if they exist. And hvmloader would need this info
later.
Signed-off-by: Tiejun Chen
---
tools/libxl/libxl_dom.c | 87 +
1 - 100 of 171 matches
Mail list logo
