> From: Zhang, Yang Z
> Sent: Wednesday, February 04, 2015 1:54 PM
>
> Tian, Kevin wrote on 2015-02-04:
> >> From: Li, Liang Z
> >> Sent: Wednesday, February 04, 2015 11:28 AM
> >>
> >> Flushing cache is needed only when guest has IOMMU device, using
> >> need_iommu(d) can minimize the impact to g
> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: Friday, January 30, 2015 5:47 AM
>
> The flag is only used for debugging purposes, thus it should be only checked
> for in debug builds of Xen.
>
> Signed-off-by: Tamas K Lengyel
> ---
> xen/arch/x86/mm/mem_sharing.c | 2 ++
>
> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: Friday, January 30, 2015 5:47 AM
>
> In preparation for allowing for introspecting ARM and PV domains the old
> control interface via the hvm_op hypercall is retired. A new control
> mechanism
> is introduced via the domctl hyperc
> From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
> Sent: Friday, January 30, 2015 5:47 AM
>
> To avoid growing hvm.c these functions can be stored
> separately.
>
> Signed-off-by: Tamas K Lengyel
VMX changes are clearly renaming:
Acked-by: Kevin Tian
> ---
> v3: Style fixes and re
Tian, Kevin wrote on 2015-02-04:
>> From: Li, Liang Z
>> Sent: Wednesday, February 04, 2015 11:28 AM
>>
>> Flushing cache is needed only when guest has IOMMU device, using
>> need_iommu(d) can minimize the impact to guest with device assigned,
>> since a guest may be hot plugged with a device thus
> From: Li, Liang Z
> Sent: Wednesday, February 04, 2015 11:28 AM
>
> Flushing cache is needed only when guest has IOMMU device, using
> need_iommu(d) can minimize the impact to guest with device assigned,
> since a guest may be hot plugged with a device thus there may be dirty
> cache lines befor
flight 34129 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 33866
build-i386-rumpuserxe
flight 34106 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34106/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 33686
build-amd64
On 02/04/2015 01:48 AM, Luis R. Rodriguez wrote:
I'm going to work on this now so my replies below.
Note: If we want feature to require XEN_PV || XEN_PVH || XEN_PVHVM,
since XEN_BACKEND depends on them I think we could just use
XEN_BACKEND as a shorthand. Furthermore if we then wanted something
flight 34094 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 26303
test-amd64-amd64-xl-qe
On 02/03/2015 07:16 PM, Kristian Hagsted Rasmussen wrote:
Hi Olaf and Juergen
I am interested in testing pvSCSI as I have a system were it would be ideal.
I have tried to apply this patch "http://marc.info/?l=xen-devel&m=139885599019457&w=2";
called "libbxl: add support for pvscsi, iteration
This enum gives the ability to select between a MiniOS-based QEMU
traditional stub domain and a Linux-based QEMU upstream stub domain. To
use the Linux-based stubdomain, the following two lines should be
included in the appropriate xl.cfg file:
device_model_version="qemu-xen"
device_model_stubdom
This patch creates an appropriate command line for the QEMU instance
running in a Linux-based stubdomain.
NOTE: a number of items are not currently implemented for Linux-based
stubdomains, such as:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric Shelton
---
tools/l
This patch builds a disk image intended to be mounted as rootfs by the
Linux stub domain. It is assembled using dracut and genext2fs.
Signed-off-by: Eric Shelton
---
stubdom-linux/.gitignore | 4 ++
stubdom-linux/Makefile| 45 +++-
stubdom-linux/extra/inits
This will build a Linux-based stubdomain with QEMU upstream.
Signed-off-by: Eric Shelton
---
tools/libxl/libxl.c | 25 --
tools/libxl/libxl_create.c | 7 ++-
tools/libxl/libxl_dm.c | 108 ---
tools/libxl/libxl_internal.c | 22 +
This patch series updates Anthony Perard's original patch series to
bring support for running QEMU upstream as a device model in a
stubdomain by using a Linux-based stubdom, rather than MiniOS as
currently used for QEMU traditional. Anthony posted the original
patch series on April 17, 2013.
The
To ensure the QEMU instance in a stubdomain is running before we unpause
an HVM guest that relies on it for a device model, we do a xenstore wait
on QEMU's indiction that it is running.
Signed-off-by: Eric Shelton
---
tools/libxl/libxl_dm.c | 46 +-
1
This patch adds a Makefile which downloads, patches, and compiles
upstream QEMU for a stubdomain based on a linux kernel.
Signed-off-by: Eric Shelton
---
stubdom-linux/.gitignore| 3 ++
stubdom-linux/Makefile | 55 +
stubdom-linux/qem
This patch adds rules to the Makefile to retrieve Linux and build a
minimal kernel for the stubdomain. Using Linux kernel 3.17.8.
In order to work as a stubdomain, two patches are applied to the Linux
kernel source.
Signed-off-by: Eric Shelton
---
stubdom-linux/.gitignore
Flushing cache is needed only when guest has IOMMU device, using
need_iommu(d) can minimize the impact to guest with device assigned,
since a guest may be hot plugged with a device thus there may be dirty
cache lines before need_iommu(d) becoming true, force the flush_all
when the first device is a
On 2015/2/3 19:07, Ian Campbell wrote:
On Tue, 2015-02-03 at 09:04 +0800, Chen, Tiejun wrote:
On 2015/2/2 20:54, Ian Jackson wrote:
Wei Liu writes ("Re: [v2][PATCH] libxl: add one machine property to support IGD GFX
passthrough"):
On Mon, Feb 02, 2015 at 09:17:23AM +0800, Tiejun Chen wrote:
On Mon, Jan 19, 2015 at 5:59 AM, Jan Beulich wrote:
On 19.01.15 at 14:28, wrote:
>> I think it is still the case that selecting an option which is user
>> visible is frowned upon?
>
> I don't think so; iirc there are cases where things deliberately get
> set up that way (for example library
I'm going to work on this now so my replies below.
Note: If we want feature to require XEN_PV || XEN_PVH || XEN_PVHVM,
since XEN_BACKEND depends on them I think we could just use
XEN_BACKEND as a shorthand. Furthermore if we then wanted something to
be available for both backend and frontend we co
On 2015/2/3 18:19, Wei Liu wrote:
On Tue, Feb 03, 2015 at 09:01:53AM +0800, Chen, Tiejun wrote:
On 2015/2/2 20:19, Wei Liu wrote:
On Mon, Feb 02, 2015 at 09:17:23AM +0800, Tiejun Chen wrote:
When we're working to support IGD GFX passthrough with qemu
upstream, instead of "-gfx_passthru" we'd
On 02/03/15 06:05, Jan Beulich wrote:
On 02.02.15 at 16:22, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2573,6 +2573,7 @@ bool_t hvm_send_assist_req_to_ioreq_server(struct
>> hvm_ioreq_server *s,
>>
>> static bool_t hvm_complete_assist_req(ioreq_t *p)
>
Thanks Ian for your helpful answer, you are right that is on Linux side but
to clear my idea , the goal is to prioritize traffic that comes from
different guest, for example if guest_1 is used for a voip server than it
would be reasonable to schedule first the vif guest_1 before other guests.
The
Thanks Zoli for your clear and very helpfull answer, my idea is to
prioritize traffic that comes from different guest, for example if guest_1
is used for a voip server than it would be reasonable to schedule first the
vif guest_1 before other guests. The diagram atached below explains better
my ide
This implements a dummy RealTimeClockLib for Xen, as there is no
guest interface to access the time kept by Xen that can be shared
between UEFI and the OS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
.../XenRealTimeClockLib/XenRealTimeClockLib.c
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
This patch adds an implementation of XenHypercallLib for both
AArch64 and AArch32 execution modes on ARM systems.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Signed-off-by: Ard Biesheuvel
---
.../Include/IndustryStandard/Xen/arch-arm/xen.h| 436 ++
This adds the .dsc and .fdf descriptions to build a UEFI image that
is bootable by a Xen guest on 64-bit ARM (AArch64)
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
.../ArmVirtualizationPkg/ArmVirtualizationXen.dsc | 218 ++
This patch adds support to XenBusDxe for executing on ARM and AArch64
machines (the former only when built with GCC).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/XenBusDxe/AtomicsGcc.c | 44 +
OvmfPkg/
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/Library/XenIoMmioLib.h
Add a ArmPlatformLib instance that can deal with the self relocation
and truly dynamic discovery of system RAM base and size.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
---
.../AARCH64/MemnodeParser.S| 232
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
Contributed-under: Tian
This introduces the abstract XENIO_PROTOCOL that will be used to
communicate the Xen grant table address to drivers supporting this
protocol. Primary purpose is allowing us to change the XenBusDxe
implementation so that it can support non-PCI Xen implementations
such as Xen on ARM.
Contributed-und
This patchs adds support to VirtFdtDxe for the Xen DT node which
contains the base address of the Grant Table. This data is communicated
to XenBusDxe using a XENIO_PROTOCOL instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
-
Prepare for making XenBusDxe suitable for use with non-PCI devices
(such as the DT node exposed by Xen on ARM) by introducing a separate
DXE driver that binds to the Xen virtual PCI device and exposes the
abstract XENIO_PROTOCOL for XenBusDxe to bind against.
Contributed-under: TianoCore Contribut
This implements a SerialPortLib instance that wires up to the
PV console ring used by domU guests. Also imports the required
upstream Xen io/console.h header.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Includ
Tiancore has its private copy of the Xen headers, and all drivers
that depend on it should use the same Xen interface version, so
let's move the #define to xen.h itself.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini
Acked-by: Laszlo Ersek
Signed-off-by:
This refactors the Xen hypercall implementation that is part of the
XenBusDxe driver, in preparation of splitting it off entirely into
a XenHypercallLib library. This involves:
- removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall()
prototypes
- moving the discovered hyperpage
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
32 bits, so casting between them needs to go via (UINTN). Also
move the xen_pfn_t cast outside the shift so that we can avoid
shifting 64-bit quantities on 32-bit architectures, which may
require runtime library support.
Contributed-un
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Contributed-under: TianoC
This patch introduces a relocatable PrePi, which can execute
from arbitrary offsets in RAM. This is intendend to be run
from a boot loader which passes a description of the actual
platform in a device tree, for instance.
This module is based on the PrePi implementations residing under
ArmPlatformP
This implements a MemoryInitPeiLib instance that differs from the
stock ArmPlatformPkg version only in the fact that it does not remove
the memory used by the flash device (FD). The reason is that, when using
PrePi, the DXE core is started immediately and never returns so there is
no reason to pres
Allow the use of patchable PCDs for gArmTokenSpaceGuid.PcdFvBaseAddress
and gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
by moving them from the [FixedPcd] to the [Pcd] section in the INF file of
PlatformPeiLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-b
In order to allow a runtime self relocating PrePi instance, change the
allowable PCD types for the following PCDs:
gArmTokenSpaceGuid.PcdSystemMemoryBase
gArmTokenSpaceGuid.PcdSystemMemorySize
gArmTokenSpaceGuid.PcdFdBaseAddress
gArmTokenSpaceGuid.PcdFvBaseAddress
to include PcdsPatchable
This series implements support for executing Tianocore inside a Xen
guest domain on 64-bit ARM systems (AArch64)
The first part addresses ARM platform specifics, primarily to allow a
Tianocore binary image to be runtime relocatable, and execute from DRAM.
The second part refactors the XenBus supp
This moves the reference to gArmTokenSpaceGuid.PcdFdBaseAddress
from the [FixedPcd] to the [Pcd] section in the INF file of
PrePiArmPlatformGlobalVariableLib so that its users may choose
to use a patchable PCD instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Ma
To allow a runtime self relocating PrePi instance to discover the base
address of the device tree at runtime, allow the use of a patchable PCD
for gArmVirtualizationTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress.
We will not be using the build time patch tool in this case, but using
a patchable PCD
Our primary user QEMU/mach-virt presents us with a FDT blob padded
to 64 KB with plenty of room to set additional properties. However,
in the general case, we should only add properties after making sure
there is enough room available.
Contributed-under: TianoCore Contribution Agreement 1.0
Review
This adds support for detecting the presence of a GICv3 interrupt
controller from the device tree, and recording its distributor and
redistributor base addresses in their respective PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek
Signed-off-by: Ard Biesheuvel
This is partially motivated by the desire to use PrePi in a virt
environment, and in that configuration, ArmPlatformInitializeSystemMemory()
is never called. But actually, this is a more suitable place anyway.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek
Revie
The DT binding for the ARM generic timer describes the secure,
non-secure, virtual and hypervisor timer interrupts, respectively.
However, under virtualization, only the virtual timer is usable, and
the device tree may omit the hypervisor timer interrupt. (Other timer
interrupts cannot be omitted s
Instead of using a dynamic PCD, store the device tree address in a HOB
so that we can also run under a configuration that does not support
dynamic PCDs.
This also adds MemoryAllocationLib to the [LibraryClasses] section of
ArmVirtualizationPlatformLib/ArmVirtualizationPlatformLib.inf, as this
depe
On Tue, Feb 03, Ian Campbell wrote:
> Olof, you just removed the nul terminator used there AFAICT. At best
> this means that the vgabios_copyright is printed twice.
My bad. Will resend. Thanks for the review.
Olaf
___
Xen-devel mailing list
Xen-devel@
On Tue, Feb 03, Andrew Cooper wrote:
> A release date is part of the SMBIOS spec, and the change below results
> in a malformed smbios table (stale p->release_date_str = 3; pointer)
Good point. Thanks for review. Do you have a pointer to that spec?
> A better approach would be to derive the date
flight 34088 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34088/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass
test-armhf-armhf-xl-sedf 10 mig
On Tue, Feb 03, 2015 at 11:05:15AM +, David Vrabel wrote:
> On 27/01/15 01:51, Luis R. Rodriguez wrote:
> >
> > +#ifndef CONFIG_PREEMPT
> > +extern struct { char _entry[32]; } preemptible_hypercall_page[];
> > +
> > +static inline bool xen_is_preemptible_hypercall(struct pt_regs *regs)
> > +{
On Tue, Feb 03, 2015 at 10:02:09AM +, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, wrote:
> > /* Save the Multiboot info struct (after relocation) for later
> > use. */
> > mov $sym_phys(cpu0_stack)+1024,%esp
> > -push%ebx
> > -callreloc
> > +
On Mon, Feb 02, 2015 at 09:28:49AM +, Jan Beulich wrote:
> >>> On 30.01.15 at 18:54, wrote:
> > - xen.efi build will not so strongly depend
> > on a given GCC and binutils version.
>
> While I can see the possibility of making the binutils version
> dependency go away (by manually creati
>>> On 03.02.15 at 17:23, wrote:
> On 03/02/15 16:15, Jan Beulich wrote:
> On 03.02.15 at 17:02, wrote:
>>> On 03/02/15 15:54, Olaf Hering wrote:
Including a timestamp into the binary makes it impossible to get
reproducible binaries. Remove the timestamp because it carries no
v
>>> On 03.02.15 at 17:28, wrote:
> On Tue, 2015-02-03 at 16:17 +, Jan Beulich wrote:
>> >>> On 03.02.15 at 17:06, wrote:
>> > On 03/02/15 15:54, Olaf Hering wrote:
>> >> Including a timestamp into the binary makes it impossible to get
>> >> reproducible binaries. Remove the timestamp because
On Tue, 2015-02-03 at 16:17 +, Jan Beulich wrote:
> >>> On 03.02.15 at 17:06, wrote:
> > On 03/02/15 15:54, Olaf Hering wrote:
> >> Including a timestamp into the binary makes it impossible to get
> >> reproducible binaries. Remove the timestamp because it carries no
> >> valuable info.
> >>
>
On Tue, 2015-02-03 at 16:23 +, Andrew Cooper wrote:
> On 03/02/15 16:18, Ian Campbell wrote:
> > On Tue, 2015-02-03 at 16:06 +, Andrew Cooper wrote:
> >> On 03/02/15 15:54, Olaf Hering wrote:
> >>> Including a timestamp into the binary makes it impossible to get
> >>> reproducible binaries.
>>> On 29.01.15 at 22:46, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -750,15 +750,15 @@ struct xen_domctl_gdbsx_domstatus {
> };
>
> /*
> - * Memory event operations
> + * VM event operations
> */
>
> -/* XEN_DOMCTL_mem_event_op */
> +/* XEN_DOMCTL_
On 03/02/15 16:15, Jan Beulich wrote:
On 03.02.15 at 17:02, wrote:
>> On 03/02/15 15:54, Olaf Hering wrote:
>>> Including a timestamp into the binary makes it impossible to get
>>> reproducible binaries. Remove the timestamp because it carries no
>>> valuable info.
>> I agree with the sentime
>>> On 29.01.15 at 22:46, wrote:
> This is the second patch in the mem_event -> vm_event migration.
> This patch migrates all previous use-cases of mem_event to use the
> new vm_event system.
>
> Signed-off-by: Tamas K Lengyel
Provided this is what it looks to be (a mechanical renaming of
mem_e
On 03/02/15 16:18, Ian Campbell wrote:
> On Tue, 2015-02-03 at 16:06 +, Andrew Cooper wrote:
>> On 03/02/15 15:54, Olaf Hering wrote:
>>> Including a timestamp into the binary makes it impossible to get
>>> reproducible binaries. Remove the timestamp because it carries no
>>> valuable info.
>>>
On Tue, 2015-02-03 at 16:06 +, Andrew Cooper wrote:
> On 03/02/15 15:54, Olaf Hering wrote:
> > Including a timestamp into the binary makes it impossible to get
> > reproducible binaries. Remove the timestamp because it carries no
> > valuable info.
> >
> > Signed-off-by: Olaf Hering
> > Cc: I
>>> On 03.02.15 at 17:02, wrote:
> On 01/30/2015 09:54 AM, Jan Beulich wrote:
> On 05.01.15 at 22:44, wrote:
>>> +static int __init vpmu_init(void)
>>> +{
>>> +int vendor = current_cpu_data.x86_vendor;
>>> +
>>> +if ( vpmu_mode == XENPMU_MODE_OFF )
>>> +{
>>> +printk(XENLO
>>> On 03.02.15 at 17:06, wrote:
> On 03/02/15 15:54, Olaf Hering wrote:
>> Including a timestamp into the binary makes it impossible to get
>> reproducible binaries. Remove the timestamp because it carries no
>> valuable info.
>>
>> Signed-off-by: Olaf Hering
>> Cc: Ian Jackson
>> Cc: Stefano S
>>> On 03.02.15 at 17:02, wrote:
> On 03/02/15 15:54, Olaf Hering wrote:
>> Including a timestamp into the binary makes it impossible to get
>> reproducible binaries. Remove the timestamp because it carries no
>> valuable info.
>
> I agree with the sentiment, but this is not how to do it.
>
> A
On 03/02/15 15:54, Olaf Hering wrote:
> Including a timestamp into the binary makes it impossible to get
> reproducible binaries. Remove the timestamp because it carries no
> valuable info.
>
> Signed-off-by: Olaf Hering
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Li
On Tue, 2015-02-03 at 16:54 +0100, Olaf Hering wrote:
> Including a timestamp into the binary makes it impossible to get
> reproducible binaries. Remove the timestamp because it carries no
> valuable info.
AFAICT this is changing the contents of a firmware table which is
exposed to the guest, so t
>>> On 03.02.15 at 16:01, wrote:
> On 03/02/15 13:55, Jan Beulich wrote:
> On 03.02.15 at 12:50, wrote:
>>> Note that spin_lock_irq() and spin_lock_irqsave() now spin with irqs
>>> disabled (previously, they would spin with irqs enabled if possible).
>>> This is required to prevent deadlocks
On 01/30/2015 09:54 AM, Jan Beulich wrote:
On 05.01.15 at 22:44, wrote:
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -497,3 +497,39 @@ long do_xenpmu_op(int op,
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
return ret;
}
+
+static int __init vpmu_init(void)
+{
+i
On 03/02/15 15:54, Olaf Hering wrote:
> Including a timestamp into the binary makes it impossible to get
> reproducible binaries. Remove the timestamp because it carries no
> valuable info.
>
> Signed-off-by: Olaf Hering
> Cc: Keir Fraser
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Ian Jackson
Including a timestamp into the binary makes it impossible to get
reproducible binaries. Remove the timestamp because it carries no
valuable info.
Signed-off-by: Olaf Hering
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Including a timestamp into the binary makes it impossible to get
reproducible binaries. Remove the timestamp because it carries no
valuable info.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/firmware/vgabios/Makefile | 11 -
>>> On 29.01.15 at 22:46, wrote:
> --- a/docs/misc/xsm-flask.txt
> +++ b/docs/misc/xsm-flask.txt
> @@ -87,6 +87,7 @@ __HYPERVISOR_domctl (xen/include/public/domctl.h)
> * XEN_DOMCTL_set_machine_address_size
> * XEN_DOMCTL_debug_op
> * XEN_DOMCTL_gethvmcontext_partial
> + * XEN_DOMCTL_vm_even
Somehow these timestamps got into the tree a long time ago.
Now they prevent reproducible hvmloader binaries.
Olaf
Olaf Hering (2):
hvmloader: remove timestamp from smbios
hvmloader: remove timestamp from vgabios
tools/firmware/hvmloader/Makefile | 1 -
tools/firmware/hvmloader/smbios.c |
On Tue, Feb 03, 2015 at 03:11:11PM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH 2/4] libxl: vcpuset: Check max_vcpus
> argument against the maximum number of vCPUs the guest has set."):
> > The maximum number of VCPUs the guest can have is determined during
> > domain creation
>>> On 29.01.15 at 22:46, wrote:
> --- a/xen/arch/x86/mm/mem_paging.c
> +++ b/xen/arch/x86/mm/mem_paging.c
> @@ -25,31 +25,29 @@
> #include
>
>
> -int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
> +int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
> {
> i
>>> On 29.01.15 at 22:46, wrote:
> -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS2
> +#define XEN_DOMCTL_MEM_EVENT_OP_MONITOR2
While this one looks okay, ...
> -#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE 0
> -#define XEN_DOMCTL_MEM_EVEN
>>> On 29.01.15 at 22:46, wrote:
> +static int hvm_memory_event_traps(long parameters, mem_event_request_t *req)
It looks like parameters isn't really a signed quantity...
> void hvm_memory_event_cr0(unsigned long value, unsigned long old)
> {
> -hvm_memory_event_traps(current->domain->ar
Konrad Rzeszutek Wilk writes ("[PATCH 2/4] libxl: vcpuset: Check max_vcpus
argument against the maximum number of vCPUs the guest has set."):
> The maximum number of VCPUs the guest can have is determined during
> domain creation and is set by 'maxvcpus' parameter (in the guest
> config). Trying t
On 03/02/15 13:55, Jan Beulich wrote:
On 03.02.15 at 12:50, wrote:
>> Use ticket locks for spin locks instead of the current byte locks.
>> Ticket locks are fair. This is an important property for hypervisor
>> locks.
>
> Isn't Linux moving to queue locks? Shouldn't we skip the intermediate
>>> On 02.02.15 at 16:22, wrote:
> Jan Beulich:
> The change on what to do when hvm_send_assist_req() fails is bad.
> That is correct. Made hvm_has_dm() do full checking so
> that the extra VMEXIT and VMENTRY can be skipped.
> hvm_complete_assist_req() be a separate function
Wei Liu writes ("Re: [PATCH OSSTEST v5 0/9] XSM test case for OSSTest"):
> On Tue, Feb 03, 2015 at 01:40:05PM +, Ian Jackson wrote:
> > Can you redo this with "| sort" after
> > ./standalone-generate-dump-flight-runvars ? That sorts the output by
> > job which in this case is probably easier t
flight 34091 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34091/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 33774
Tests which did not succee
On Tue, Feb 03, 2015 at 01:40:55PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH OSSTEST v5 1/9] overlay: update
> overlay/etc/grub.d/20_linux_xen"):
> > This file was originally created to work around Debian bug #633127
> > ("/etc/grub/20_linux does not recognise some old Xen kernels").
> >
On Tue, Feb 03, 2015 at 01:55:01PM +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH OSSTEST v5 9/9] mfi-common, make-flight: create XSM
> test jobs"):
> > Duplicate Debian PV and HVM test jobs for XSM testing.
> ...
> > do_hvm_debian_tests() {
> > + test_xsm=$(xenbranch_xsm_variants)
>
> Thi
On Tue, 2015-02-03 at 12:09 +, Lars Kurth wrote:
> the patch series for modifications to
> http://www.xenproject.org/security-policy.html has gone it's second
> revision and is ready for voting. In accordance with our governance,
> committers are eligible to vote. Others can of course voice the
On Tue, 2015-02-03 at 14:10 +, Wei Liu wrote:
> On Tue, Feb 03, 2015 at 01:41:45PM +, Ian Campbell wrote:
> > On Tue, 2015-02-03 at 13:40 +, Ian Jackson wrote:
> > > > Changes in v5 can be found in individual patch.
> > > >
> > > > See below for output of
> > > > ./standalone-generat
On Tue, Feb 03, 2015 at 01:41:45PM +, Ian Campbell wrote:
> On Tue, 2015-02-03 at 13:40 +, Ian Jackson wrote:
> > > Changes in v5 can be found in individual patch.
> > >
> > > See below for output of
> > > ./standalone-generate-dump-flight-runvars > origin # master
> > > ./standalone-g
> -Original Message-
> From: Paul Durrant
> Sent: 03 February 2015 14:00
> To: Ian Campbell
> Cc: Wei Liu; xen-devel@lists.xen.org; Ian Jackson; Jan Beulich; Andrew
> Cooper; Stefano Stabellini
> Subject: RE: Stubdom breakage in 4.5
>
> > -Original Message-
> > From: Ian Campbell
>
At 12:09 + on 03 Feb (1422961751), Lars Kurth wrote:
> the patch series for modifications to
> http://www.xenproject.org/security-policy.html has gone it's second
> revision and is ready for voting. In accordance with our governance,
> committers are eligible to vote. Others can of course voice
The current Python interface to Xenstore is just a thin binding to the
C libxenstore library. This means that it is architecture-specific and
makes it awkward to use in platform-independent code like the XenServer
guest agent.
The Xenstore protocol is simple and quite straightforward to implement
> -Original Message-
> From: Ian Campbell
> Sent: 03 February 2015 13:48
> To: Paul Durrant
> Cc: Wei Liu; xen-devel@lists.xen.org; Ian Jackson; Jan Beulich; Andrew
> Cooper; Stefano Stabellini
> Subject: Re: Stubdom breakage in 4.5
>
> On Tue, 2015-02-03 at 13:42 +, Paul Durrant wrote
1 - 100 of 204 matches
Mail list logo
