On 12/02/15 19:44, Wei Liu wrote:
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/xl_cmdimpl.c | 12
1 file changed, 12 insertions(+)
diff --git a/tools/libxl/xl_cmdimpl.c
Please do not top post.
On 12/02/15 18:19, D'Mita Levy wrote:
Andrew,
My apologies if my logic is flawed or what I am describing is
convoluted - I am a student doing research into Xen and trying my best
to grasp what is going on, also my ASM is subpar. I have read a paper
on system call
A domain can contain several virtual NUMA nodes, hence we introduce an
array in libxl_domain_build_info.
libxl_vnode_info contains the size of memory in that node, the distance
from that node to every nodes, the underlying pnode and a bitmap of
vcpus.
Signed-off-by: Wei Liu wei.l...@citrix.com
Signed-off-by: Elena Ufimsteva ufimts...@gmail.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
---
Changes in v5:
1. Use read_trylock.
2. Use correct array size for strlcpy.
3. Coding style fix.
Changes in v4:
1. Acquire rwlock before accessing vnuma struct.
2.
This function gets the machine E820 map and sanitize it according to PV
guest configuration.
This will be used in later patch. No functional change introduced in
this patch.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson
A vnode consists of one or more vmemranges (virtual memory range). One
example of multiple vmemranges is that there is a hole in one vnode.
Currently we haven't exported vmemrange interface to libxl user.
Vmemranges are generated during domain build, so we have relevant
structures in domain
Add a new field p2m_size to keep track of the number of pages covert by
p2m. Change total_pages to p2m_size in functions which in fact need
the size of p2m.
This is needed because we are going to ditch the assumption that PV x86
has only one contiguous ram region. Originally the p2m size was
Coverity uses several heuristics to identify when one case statement
legitimately falls through into the next, and a comment as the final item in a
case statement is one heuristic (the assumption being that it is a
justification for the fallthrough).
Use this to perform an audit of defects and
Wei Liu writes (Re: [PATCH OSSTEST 01/12] Add support of parsing grub which
has 'submenu' primitive):
On Thu, Feb 12, 2015 at 02:01:59AM +, Hu, Robert wrote:
Yes, this minor change just get 'parsemenu' subroutine capability of
recognizing 'submenu'.
The outer layer logic isn't
The algorithm is more or less the same as the one used for PV guest.
Libxc gets hold of the mapping of vnode to pnode and size of each vnode
then allocate memory accordingly.
And then the function returns low memory end, high memory end and mmio
start to caller. Libxl needs those values to
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/xl_cmdimpl.c | 12
1 file changed, 12 insertions(+)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 440db78..ec7fb2d
Transform user supplied vNUMA configuration into libxl internal
representations then libxc representations. Check validity along the
line.
Libxc has more involvement in building vmemranges in HVM case compared
to PV case. The building of vmemranges is placed after xc_hvm_build
returns, because it
Move a while loop in xc_hvm_build_x86 one block to the right. No
functional change introduced.
Functional changes will be introduced in next patch.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Dario Faggioli
Andrew,
My apologies if my logic is flawed or what I am describing is convoluted -
I am a student doing research into Xen and trying my best to grasp what is
going on, also my ASM is subpar. I have read a paper on system call
interception (
Hi guys,
I am forwarding this message after initially having confirmed with Ian
Campbell on the user list that there's really an issue - please see
further below.
I am currently running xen-4.3.3 on gentoo (dom0 is based on kernel
3.17.7) and I am happy to help out by applying and testing
Coverity uses several heuristics to identify when one case statement
legitimately falls through into the next, and a comment as the final item in a
case statement is one heuristic (the assumption being that it is a
justification for the fallthrough).
Use this to perform an audit of defects and
Jim Fehlig writes (Re: [PATCH 3/3] libxl: libxl__device_from_disk should
retrieve backend from xenstore):
Wei Liu wrote:
On Tue, Feb 10, 2015 at 11:01:46AM +, Ian Jackson wrote:
What should happen if the caller specifies a different target in disk
to the one the device is actually
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/libxl.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c219f59..f33178c 100644
---
This patch includes configuration options parser and documentation.
Please find the hunk to xl.cfg.pod.5 for more information.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
Changes in v5:
1. New syntax for vNUMA
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Jan Beulich jbeul...@suse.com
---
Changes in v3:
1. Remove redundant variable.
2. Coding style fix.
3. Add assertion.
Changes in v2:
1. Remove explicit zero initializers.
2. Adapt to new vNUMA retrieval routine.
3. Move SRAT very late in
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Jan Beulich jbeul...@suse.com
---
Changes in v3:
1. Coding style fix.
2. Fix an error code.
3. Use unsigned int for loop variable.
Changes in v2:
1. Adapt to new vNUMA retrieval routine.
2. Move SLIT very late in secondary table build.
---
Introduce a arch-independent routine to generate one vmemrange per
vnode. Also introduce arch-dependent routines for different
architectures because part of the process is arch-specific -- ARM has
yet have NUMA support and E820 is x86 only.
For those x86 guests who care about machine E820 map
These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList.
APIs introduced:
1. xlu_cfg_value_type
2. xlu_cfg_value_get_string
3. xlu_cfg_value_get_list
4. xlu_cfg_get_listitem2
Move some definitions from private header to public header as needed.
Signed-off-by: Wei Liu
Transform the user supplied vNUMA configuration into libxl internal
representations, and finally libxc representations. Check validity of
the configuration along the line.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Disallow memory relocation when vNUMA is enabled, because relocated
memory ends up off node. Further more, even if we dynamically expand
node coverage in hvmloader, low memory and high memory may reside
in different physical nodes, blindly relocating low memory to high
memory gives us a
1. Extend grammar of parser.
2. Adjust internal functions to accept XLU_ConfigValue instead of
char *.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
Robert Ho writes ([PATCH OSSTEST 11/12] Changes on test step of debain hvm
guest install):
This patch is to make ts-debian-hvm-install accomodate
Ah yes here is the meat.
Firstly, can you please reformat your commit message so that the
individual points are separated out into paragraphs. But
This function is used to check whether vNUMA configuration (be it
auto-generated or supplied by user) is valid.
Define a new error code ERROR_VNUMA_CONFIG_INVALID.
The checks performed can be found in the comment of the function.
This vNUMA function (and future ones) is placed in a new file
From libxc's point of view, it only needs to know vnode to pnode mapping
and size of each vnode to allocate memory accordingly. Add these fields
to xc_dom structure.
The caller might not pass in vNUMA information. In that case, a dummy
layout is generated for the convenience of libxc's allocation
Currently all in tree code doesn't set the superpage flag, but Konrad
wants it retained for the moment.
As I'm going to change the p2m_host array allocation, duplicate the code
snippet to allocate p2m_host array in this patch, so that we retain the
behaviour in superpage case.
This patch
Make XENMEM_increase_reservation and XENMEM_populate_physmap
vNUMA-aware.
That is, if guest requests Xen to allocate memory for specific vnode,
Xen can translate vnode to pnode using vNUMA information of that guest.
XENMEMF_vnode is introduced for the guest to mark the node number is in
fact
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
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
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
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
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
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 ler...@redhat.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Signed-off-by: Ard
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
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
Reviewed-by: Olivier Martin olivier.mar...@arm.com
This implements the following synchronization primitives for AArch64 (GCC)
and ARM (GCC RVCT):
InternalSyncCompareExchange32
InternalSyncCompareExchange64
InternalSyncIncrement
InternalSyncDecrement
Note: these functions are implemented using the exclusive monitor,
which implies that they can
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
Thursday, February 12, 2015, 12:28:35 PM, you wrote:
Hello,
El 12/02/15 a les 9.54, Sander Eikelenboom ha escrit:
Hi,
With a 3.19 kernel + xen-devel tree pulled on top i run into this splat
below.
It's on a Xen PV-guest running a postgres database and doing a pg_dump at
that
moment
I think that’s an answer to why hlt is a vmexit as opposed to when it is likely
to occur…
This simple answer, of course, is the OS idle process will most likely the
issuer of a hlt instruction and this is why you are seeing them so frequently.
Give your guest some compute-bound task and you’ll
On Thu, Feb 12, 2015 at 11:09:52AM +, Lars Kurth wrote:
On 12/02/2015 11:07, Wei Liu wei.l...@citrix.com wrote:
Thanks. I think your new pictures are accurate.
Wei.
In that case, I will re-upload that presentation I shared earlier. It will
show the pre 4.5 workflow and new
On 12/02/2015 11:07, Wei Liu wei.l...@citrix.com wrote:
Thanks. I think your new pictures are accurate.
Wei.
In that case, I will re-upload that presentation I shared earlier. It will
show the pre 4.5 workflow and new proposal
Regards
Lars
___
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.
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
This implements the function InterlockedCompareExchange16 () for all
architectures, using architecture and toolchain specific intrinsics
or primitive assembler instructions.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Signed-off-by:
This patch updates XenBusDxe to use the 16-bit compare and exchange
function that was introduced for this purpose to the
BaseSynchronizationLib. It also provides a new generic implementation
of TestAndClearBit () using the same 16-bit compare and exchange, making
this module fully architecture
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 ler...@redhat.com
Reviewed-by:
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 stefano.stabell...@eu.citrix.com
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
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:
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
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
Acked-by: Laszlo Ersek ler...@redhat.com
Reviewed-By: Olivier Martin
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
Reviewed-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Ard Biesheuvel
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 ler...@redhat.com
Signed-off-by:
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:
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 ler...@redhat.com
Reviewed-by: Olivier Martin olivier.mar...@arm.com
Signed-off-by: Ard Biesheuvel
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 stefano.stabell...@eu.citrix.com
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
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.
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 stefano.stabell...@eu.citrix.com
Acked-by: Laszlo
On Wed, Feb 11, 2015 at 04:12:24PM +, Ian Jackson wrote:
Wei Liu writes ([PATCH v4 18/21] libxlu: rework internal representation of
setting):
This patches does following things:
...
+void xlu__cfg_list_append(CfgParseContext *ctx,
+ XLU_ConfigValue *list,
+
On Wed, Feb 11, 2015 at 04:17:19PM +, Ian Jackson wrote:
Wei Liu writes ([PATCH v4 20/21] libxlu: introduce new APIs):
These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList.
...
+const char *xlu_cfg_value_get_string(const XLU_ConfigValue *value)
+{
+
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets us rip out under the general XEN config the
XEN_HAVE_PVMMU dependency. This only exists on the x86
universe. This is as per the agreed upon Xen Kconfig
changes [0].
[...]
@@ -52,3 +51,9 @@ config
On Wed, Feb 11, 2015 at 02:54:46PM +, Lars Kurth wrote:
On 11/02/2015 12:27, Wei Liu wei.l...@citrix.com wrote:
On Wed, Feb 11, 2015 at 12:20:20PM +, Lars Kurth wrote:
Wei,
this sounds reasonable. I just wanted to ensure that I understood fully?
Do you want me to update
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Here's the first shot at the Kconfig changes for Xen as discussed
on the mailing list a little while ago [0]. Let me know if you spot
any issues or if you'd like things split differently. I tried to
make
Hello,
El 12/02/15 a les 9.54, Sander Eikelenboom ha escrit:
Hi,
With a 3.19 kernel + xen-devel tree pulled on top i run into this splat below.
It's on a Xen PV-guest running a postgres database and doing a pg_dump at that
moment in time, after running for a while (within 2 days or so).
This patch registers hvc0 as the preferred console if no console
has been specified explicitly on the kernel command line.
The purpose is to allow platform agnostic kernels and boot images
(such as distro installers) to boot in a Xen/ARM domU without the
need to modify the command line by hand.
On Thu, Feb 12, 2015 at 01:23:26AM +, Ni, Ruiyu wrote:
Wei,
No you cannot install gEfiPciEnumerationCompleteProtocolGuid in
PciEnumeratorLight().
For a real platform, PCI BUS is fully enumerated in PciEnumerator()
and later if reconnect happens, it's light enumerated in
On 02/11/15 21:23, Wei Liu wrote:
I had an issue when trying to boot Xen HVM guest with latest OVMF
master. Guest crashed with memory violation, and the bisection pointed
to 66b280df2 (OvmfPkg: AcpiPlatformDxe: make dependency on PCI
enumeration explicit). That commit made AcpiPlatformDxe
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This unwraps XEN_BACKEND from depending on XEN_DOM0, it
instead makes it depend on the possible x86 backends and
under what scenerios its allowed under ARM. This is as per
the agreed upon Xen Kconfig changes
On 11/02/15 20:58, Boris Ostrovsky wrote:
If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START)
is passed for %*ph/%pv/%ps/%pS format specifiers then print (NULL)
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
xen/common/vsprintf.c | 23
On 12 February 2015 at 14:34, Julien Grall julien.gr...@linaro.org wrote:
Hello,
This small patch series move the detection of running on Xen earlier. This is
required in order to support earlyprintk via Xen and selecting the preferred
console.
Ard, the patch to move the call earlier (see
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
if (unlikely(lock-tickets.tail
On Thu, Feb 12, 2015 at 02:01:59AM +, Hu, Robert wrote:
-Original Message-
From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
Sent: Wednesday, February 11, 2015 10:44 PM
To: Hu, Robert
Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
Hi all,
I am assuming this question is in effect resolved. The proposed (and agreed)
text basically states that security advisories state whether people will be
allowed to deploy. The underlying assumption is that usually this is the case,
unless there is a very good reason not to. How the
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Fold Xen front end drivers under their own Kconfig entry.
You may want to for example only enable domU guests with
pv-drivers.
While at it make HVC_XEN_FRONTEND select HVC_XEN.
[...]
---
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should only be
downloaded after PCI enumeration.
However, InitializeXen() in OvmfPkg/PlatformPei/Xen.c sets
PcdPciDisableBusEnumeration to TRUE. This causes
On Thu, Feb 12, 2015 at 11:01:52AM +, David Vrabel wrote:
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Fold Xen front end drivers under their own Kconfig entry.
You may want to for example only enable domU guests with
pv-drivers.
While at
On 2015-02-11 17:23:26, Ni, Ruiyu wrote:
Wei,
No you cannot install gEfiPciEnumerationCompleteProtocolGuid in
PciEnumeratorLight().
For a real platform, PCI BUS is fully enumerated in PciEnumerator()
and later if reconnect happens, it's light enumerated in
PciEnumeratorLight(). The protocol
On Thu, Feb 12, 2015 at 09:55:18AM +, David Vrabel wrote:
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
These are Kconfig options which are known to only make
sense with Xen dom0 support. This is as per the agreed
upon changes to Xen's kconfig
On Thu, Feb 12, 2015 at 09:56:30AM +, David Vrabel wrote:
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Although XEN currently selects XEN_HAVE_PVMMU that will not
be the case in the near future so select this requirement
explicitly as per the
I think gEfiPciEnumerationCompleteProtocolGuid should be installed by
MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisableBusEnumeration
is set.
Ray's main feedback seemed to be that we need to make sure PciBusDxe
only installs the protocol once. (I'll also reply to the other related
patch
On Thu, Feb 12, 2015 at 11:05:14AM +, David Vrabel wrote:
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This unwraps XEN_BACKEND from depending on XEN_DOM0, it
instead makes it depend on the possible x86 backends and
under what scenerios its
Do you have this in a public branch based on this tree?
https://github.com/tianocore/edk2
On 2015-02-12 03:18:52, Ard Biesheuvel wrote:
This series implements support for executing Tianocore inside a Xen
guest domain on 64-bit ARM systems (AArch64)
The first part addresses ARM platform
On Thu, 12 Feb 2015 20:08:33 +
Andrew Cooper andrew.coop...@citrix.com wrote:
Coverity uses several heuristics to identify when one case statement
legitimately falls through into the next, and a comment as the final item in a
case statement is one heuristic (the assumption being that it is
Jordan,
You are correct that subsequent installations of this protocol will fail.
But I don't think locating this protocol before installing it is a good
implementation choice. This would make the code confusing.
Thanks,
Ray
-Original Message-
From: Justen, Jordan L
Sent: Friday,
Ian,
Just ping this, or do you think I should send this as a patch?
Thanks
Tiejun
On 2015/2/11 10:45, Chen, Tiejun wrote:
On 2015/2/9 19:05, Ian Campbell wrote:
On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote:
What about this?
I've not read the code in detail,since I'm travelling
On 13 February 2015 at 05:18, Jordan Justen jordan.l.jus...@intel.com wrote:
Do you have this in a public branch based on this tree?
https://github.com/tianocore/edk2
The patches are available here
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/linaro-topic-xen
flight 34477 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34477/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488
Hi,
With a 3.19 kernel + xen-devel tree pulled on top i run into this splat below.
It's on a Xen PV-guest running a postgres database and doing a pg_dump at that
moment in time, after running for a while (within 2 days or so).
--
Sander
[139595.736073] [ cut here ]
Hi, all:
I was testing networking performance from DomU to DomU running on
different hosts. I used xentrace and xenalyze tools to get the trace info of
receive side, and found that there was a time when vcpus (which handle the
receive work) were in Blocked state. From the information
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
These are Kconfig options which are known to only make
sense with Xen dom0 support. This is as per the agreed
upon changes to Xen's kconfig changes [0].
[...]
--- a/arch/x86/xen/Kconfig
+++
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
Although XEN currently selects XEN_HAVE_PVMMU that will not
be the case in the near future so select this requirement
explicitly as per the agreed upon Kconfig changes [0].
[...]
--- a/arch/x86/xen/Kconfig
On 12/02/15 09:24, zhangtrump wrote:
Hi, all:
I was testing networking performance from DomU to DomU running on
different hosts. I used xentrace and xenalyze tools to get the trace
info of receive side, and found that there was a time when vcpus
(which handle the receive work) were in
On 02/12/2015 08:34 PM, Tim Deegan wrote:
Hi,
Thanks for posting this design!
At 16:28 +0800 on 11 Feb (1423668493), Kai Huang wrote:
Design
==
- PML feature is used globally
A new Xen boot parameter, say 'opt_enable_pml', will be introduced to control
PML feature detection, and PML
## ### # # #
# # # ### # #
# # # # # # #
### # # # #
# # # # # # #
# # ### # #
#### # # #
David still wants a comment from the x86 maintainers...
Juergen
On 01/21/2015
On 02/12/2015 08:42 PM, Tim Deegan wrote:
At 07:08 + on 12 Feb (1423721283), Tian, Kevin wrote:
for general log dirty, ept_invalidate_emt is required because there is
access permission change (dirtied page becomes rw after 1st fault,
so need to change them back to ro again for the new
On Thu, Feb 12, 2015 at 11:03:26AM +, David Vrabel wrote:
On 12/02/15 06:03, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets us rip out under the general XEN config the
XEN_HAVE_PVMMU dependency. This only exists on the x86
universe. This is as per the
1 - 100 of 155 matches
Mail list logo
