> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, November 21, 2014 3:54 PM
>
> >>> On 21.11.14 at 08:43, wrote:
> >> From: Chen, Tiejun
> >> Sent: Friday, November 21, 2014 2:26 PM
> >>
> >> On 2014/11/3 18:02, Jan Beulich wrote:
> >> On 03.11.14 at 10:55, wrote:
> >> >> On 2
Hi,
while testing my "linear p2m list" patches I saw the following
problem (even without my patches in place):
In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
disk image of a guest by attaching it to dom0:
xl block-attach 0 file:/var/lib/libvirt/images/opensuse13-1/xvda,xvda,w
>>> On 20.11.14 at 21:07, wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to
> fiddle with the C states?
For that I'd first of all like to know how much use of C states the
system still makes with that option in place. For that I'd need the
output of "xenpm get-cpuid
On 2014/11/21 15:54, Jan Beulich wrote:
On 21.11.14 at 08:43, wrote:
From: Chen, Tiejun
Sent: Friday, November 21, 2014 2:26 PM
On 2014/11/3 18:02, Jan Beulich wrote:
On 03.11.14 at 10:55, wrote:
On 2014/11/3 17:45, Jan Beulich wrote:
On 03.11.14 at 10:32, wrote:
On 2014/11/3 16:53, Ja
On Thu, 2014-11-20 at 16:53 -0700, Xing Lin wrote:
> I git clone nova-juno from github and searched for 'pygrub'. Here is what i
> get.
>
>
> .//etc/nova/rootwrap.d/compute.filters:104:# nova/virt/xenapi/vm_utils.py:
> 'pygrub', '-qn', dev_path
> .//etc/nova/rootwrap.d/compute.filters:105:pyg
>>> On 20.11.14 at 21:07, wrote:
> Running with mwait-idle=0 solves (hides?) the problem. Next step is to
> fiddle with the C states?
So this also prompted me to go over the list of errata. Just to confirm
- your CPU is family 6 model 44? What stepping? And what nominal
frequency?
There are a c
>>> On 21.11.14 at 09:54, wrote:
> On 2014/11/21 15:54, Jan Beulich wrote:
> On 21.11.14 at 08:43, wrote:
>>> it's natural to get reserved information once, and then saved for either
>>> one-time or multiple-time references.
>>
>> Not really natural, but possible. Yet if done this way, then t
On Thu, 2014-11-20 at 18:28 +, Andrew Cooper wrote:
> Realistically, this means no updates to the
> p2m at all, due to several potential race conditions.
>From the rest of the mail it seems as if you are talking primarily about
changes to the p2m *structure*, i.e. which guest frames contain th
Hi,
during tests of my "linear p2m list" patches I stumbled over some
WARNs issued during xl save and xl restore of a pv-domU with
unpatched linux 3.18-rc5:
during save I saw multiple entries like:
[ 176.900393] WARNING: CPU: 0 PID: 9 at arch/x86/xen/enlighten.c:968
clear_local_APIC+0xa5/0x2b0
On 21/11/14 09:43, Ian Campbell wrote:
> On Thu, 2014-11-20 at 18:28 +, Andrew Cooper wrote:
>> Realistically, this means no updates to the
>> p2m at all, due to several potential race conditions.
> From the rest of the mail it seems as if you are talking primarily about
> changes to the p2m *s
On 21/11/14 05:41, Juergen Gross wrote:
> On 11/20/2014 07:28 PM, Andrew Cooper wrote:
>> Hello,
>>
>> Tim, David and I were discussing this over lunch. This email is a
>> (hopefully accurate) account of our findings, and potential solutions.
>> (If I have messed up, please shout.)
>>
>> Currently
>>> On 20.11.14 at 19:28, wrote:
> Should the guest change the p2m structure during live migration, the
> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
> resulting in bogus cross-referencing. Should the guest change an entry
> in the p2m, the p2m frame itself will be rese
On Fri, 2014-11-21 at 10:24 +, Andrew Cooper wrote:
> On 21/11/14 09:43, Ian Campbell wrote:
>
> > On Thu, 2014-11-20 at 18:28 +, Andrew Cooper wrote:
> > > Realistically, this means no updates to the
> > > p2m at all, due to several potential race conditions.
> > From the rest of the mail
On 21/11/14 10:43, Jan Beulich wrote:
On 20.11.14 at 19:28, wrote:
>> Should the guest change the p2m structure during live migration, the
>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>> resulting in bogus cross-referencing. Should the guest change an entry
>> in
On Thu, 2014-11-20 at 22:13 -0500, Gedalya wrote:
> On 11/20/2014 03:21 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 20, 2014 at 03:48:47PM +, Ian Campbell wrote:
> >> The libxc xc_dom_* infrastructure uses a very simple malloc memory pool
> >> which
> >> is freed by xc_dom_release. Howeve
Il 20/11/2014 12:21, Fabio Fantoni ha scritto:
Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
Il 08/07/2014 12:34, Fabio Fantoni ha scritto:
Il 08/07/2
On 21/11/14 10:46, Ian Campbell wrote:
> On Fri, 2014-11-21 at 10:24 +, Andrew Cooper wrote:
>> On 21/11/14 09:43, Ian Campbell wrote:
>>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
>>> here, where does that fit in?
>>>
>> It is referenced several times, although not b
On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
> When parsing bitmap objects JSON parser will create libxl_bitmap
> map of the smallest size needed.
>
> This can cause problems when saved image file specifies CPU affinity.
> For example, if 'vcpu_hard_affinity' in the saved image
On Fri, 2014-11-21 at 11:03 +, Ian Campbell wrote:
> http://man7.org/linux/man-pages/man3/mallopt.3.html also talks about
> various dynamic thresholds for growing and shrinking the heap. My guess
> is that we are bouncing up and down over some threshold with every other
> reboot.
IOW I'm not o
On Fri, 2014-11-21 at 11:07 +, Andrew Cooper wrote:
> On 21/11/14 10:46, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 10:24 +, Andrew Cooper wrote:
> >> On 21/11/14 09:43, Ian Campbell wrote:
> >>> I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> >>> here, where does
On 11/21/2014 12:15 PM, Ian Campbell wrote:
On Fri, 2014-11-21 at 11:07 +, Andrew Cooper wrote:
On 21/11/14 10:46, Ian Campbell wrote:
On Fri, 2014-11-21 at 10:24 +, Andrew Cooper wrote:
On 21/11/14 09:43, Ian Campbell wrote:
I don't see any (explicit) mention of the pfn_to_mfn_frame_
On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
> On 11/21/2014 12:15 PM, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 11:07 +, Andrew Cooper wrote:
> >> On 21/11/14 10:46, Ian Campbell wrote:
> >>> On Fri, 2014-11-21 at 10:24 +, Andrew Cooper wrote:
> On 21/11/14 09:43, Ian C
On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bit
On Thu, 20 Nov 2014, David Vrabel wrote:
> On a Xen PV guest the DMA addresses and physical addresses are not 1:1
> (such as Xen PV guests) and the generic dma_get_required_mask() does
> not return the correct mask (since it uses max_pfn).
>
> Some device drivers (such as mptsas, mpt2sas) use
> dm
On Mon, 17 Nov 2014, Stefano Stabellini wrote:
> Hi all,
> I am writing this email to ask for your advice.
>
> On architectures where dma addresses are different from physical
> addresses, it can be difficult to retrieve the physical address of a
> page from its dma address.
>
> Specifically this
On November 21, 2014 2:51:33 AM EST, Jan Beulich wrote:
On 20.11.14 at 20:51, wrote:
>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>struct hvm_pirq_dpci *pirq_dpci)
>> ASSERT(d->arch.hvm_domain.irq.dpci);
>>
>> spin_lock(&d->event_lock);
>> -if ( pirq_d
>>> On 21.11.14 at 12:50, wrote:
> On November 21, 2014 2:51:33 AM EST, Jan Beulich wrote:
> On 20.11.14 at 20:51, wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>> ASSERT(d->arch.hvm_domain.irq.dpci);
>>>
>>> spin
>>> On 21.11.14 at 12:24, wrote:
> On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
>> On 11/21/2014 12:15 PM, Ian Campbell wrote:
>> > On Fri, 2014-11-21 at 11:07 +, Andrew Cooper wrote:
>> >> On 21/11/14 10:46, Ian Campbell wrote:
>> >>> On Fri, 2014-11-21 at 10:24 +, Andrew Coope
On 11/21/2014 01:15 PM, Jan Beulich wrote:
On 21.11.14 at 12:24, wrote:
On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
On 11/21/2014 12:15 PM, Ian Campbell wrote:
On Fri, 2014-11-21 at 11:07 +, Andrew Cooper wrote:
On 21/11/14 10:46, Ian Campbell wrote:
On Fri, 2014-11-21 at 10
>>> On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -224,7 +224,12 @@ struct arch_shared_info {
> /* Frame containing list of mfns containing list of mfns containing p2m.
> */
> xe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-9030 / XSA-113
version 2
Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
=
>>> On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
> The XENVER_get_features sub command of the xen_version hypercall is
> handled completely in common/kernel.c despite of some architecture
> dependant parts.
>
> Move the architecture dependant parts in an own function in
> arc
Friday, November 21, 2014, 12:50:16 PM, you wrote:
> On November 21, 2014 2:51:33 AM EST, Jan Beulich wrote:
> On 20.11.14 at 20:51, wrote:
>>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>>struct hvm_pirq_dpci *pirq_dpci)
>>> ASSERT(d->arch.hvm_domain.irq.dpci);
On 11/21/2014 01:23 PM, Jan Beulich wrote:
On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -224,7 +224,12 @@ struct arch_shared_info {
/* Frame containing list of mfns containing list of m
$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret
it properly. See http://lists.denx.de/pipermail/u-boot/2014-October/193622.html
Signed-off-by: Ian Campbell
---
v3: Reference ML thread.
v2: New patch, previously included in "Osstest/Debian: Workaround oddities in
This is done whenever dtbs.tar.gz exists. mg-debian-installer-update produces
the necessary inputs on the relevant platform (armhf).
Signed-off-by: Ian Campbell
---
v3: More careful check/stat for existence of dtbs.tar.gz
v2: Install dtbs iff dtbs.tar.gz exists.
---
Osstest/Debian.pm | 28 ++
dom0 is not aware that some clocks are actually in use (e.g. by the
hypervisor), so this stops the kernel from messing with (specifically,
disabling) those clocks. It's harmless even when not needed.
Really there ought to be some interface to communicate this from Xen to dom0,
or some other mechan
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Osstest/Debian.pm | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..33a4ca4 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -660,9 +660,15 @@ END
arndale appears to be quite slow (and asynchronous) at finding it's scsi
controller. rootdelay=3 seems to do the trick.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Osstest/Debian.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8b704
The currently supported platform provides an FDT preloaded at 0x1000. Replace
this with ${fdt_addr} (which the current platform exposes) and for platforms
which do not provide an fdt arrange to load the relevant file as named in the
${fdtfile} (which is conventionally provided by u-boot for platfor
The arndale platform needs a bunch of clk, phy and regulator stuff in order to
access its root filesystem. However mkinitramfs is not (currently?) able to
figure this out and therefore doesn't include them in the initrd. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042
Add a new host p
This saves repeating identical HostProp and HostFlags for sets of identical
machines. e.g.
HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
HostGroupProp_cubietruck_Build_Make_Flags -j12
HostGroupProp_cubietruck_XenSerialConsole dtuart
HostGroupProp_cubietruck_XenDTUARTPath /soc@0
Uses DebianNonfreeFirmware, even (especially) for production, so move the
README stanza out of standalone only section. The current default matches what
is in the current production versions of DI.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
README | 16 +++
Various drivers are missing from multi_v7_defconfig in v3.16, also some drivers
which don't play nice are enabled by default, so remove them.
Signed-off-by: Ian Campbell
---
v3: This is a more extensive version of "ts-kernel-build: Enable
CONFIG_PHY_EXYNOS5250_SATA". Ian acked that but this does
This ensures that we always have a boot script to boot at least the native
Debian kernel and Xen available, even after multiple iterations of
installation, which is handy when debugging a system.
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 14 --
1 file changed, 8 insertions(
Unlike x86 there is enough variation in the ARM platforms that it is worth
having a basic test on each as part of a standard run. This relies on each host
having an appropriate platform-$platform host flag.
The existing test-ARCH-ARCH-xl test is retained as a floating test, while a new
variant is
This makes the kernel's .config available in /proc/config.gz and embeds a copy
which can be extracted with linux/scripts/extract-ikconfig (which I've not
tried, but have no reason to doubt).
Having this around can be handy with an older osstest installed test box and to
confirm you've booted the k
This depends on a change to the hostdb to add "0x0100" as the value of a
new UBootSetXenAddrR property of the midway machines.
Most platforms will need something similar. For both cubietruck and arndale
0x4100.
Signed-off-by: Ian Campbell
---
v3: Move the property to a specific one like
On Thu, 2014-11-20 at 17:37 +, Ian Campbell wrote:
> This series
Which I fat fingered and sent to "xendevel" instead of xen-devel@lists.
I've just resent with the right things. Sorry for the noise.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.x
This controls the eth008 relay board:
http://www.robot-electronics.co.uk/htm/eth008tech.htm
Due to the use of the CGI interface this requires firmware version 4+.
Signed-off-by: Ian Campbell
---
v3: Use LWP::UserAgent
v2: Pass username and password via a netrc file.
---
Osstest/PDU/eth008.pm |
On 21/11/14 12:57, Juergen Gross wrote:
> On 11/21/2014 01:23 PM, Jan Beulich wrote:
> On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
>>> --- a/xen/include/public/arch-x86/xen.h
>>> +++ b/xen/include/public/arch-x86/xen.h
>>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>>
Hi Juergen,
On 11/14/2014 09:37 AM, Juergen Gross wrote:
> The XENVER_get_features sub command of the xen_version hypercall is
> handled completely in common/kernel.c despite of some architecture
> dependant parts.
>
> Move the architecture dependant parts in an own function in
> arch/*/domain.c
On 20/11/14 16:45, Boris Ostrovsky wrote:
> On 11/20/2014 11:15 AM, Ian Campbell wrote:
>> On Thu, 2014-11-20 at 16:08 +, Andrew Cooper wrote:
>>> On 20/11/14 16:00, Ian Campbell wrote:
On Mon, 2014-11-17 at 15:19 +, Andrew Cooper wrote:
> c/s d1b93ea causes substantial functional
On 11/21/2014 02:26 PM, Andrew Cooper wrote:
On 21/11/14 12:57, Juergen Gross wrote:
On 11/21/2014 01:23 PM, Jan Beulich wrote:
On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -224,7 +224,12 @
On Thu, 2014-11-20 at 18:07 +, Ian Jackson wrote:
> + Automatic runs create a new ownd task for each job (in become-task
At first I thought ownd was a typo for owned, but I see that it is
called this in the source...
> +The main client in the planning process is
> +ts-hosts-allocate-Execut
On Fri, Nov 21, 2014 at 09:42:11AM +0100, Juergen Gross wrote:
> Hi,
>
> while testing my "linear p2m list" patches I saw the following
> problem (even without my patches in place):
>
> In dom0 running linux 3.18-rc5 on top of Xen 4.4.1 I modified the
> disk image of a guest by attaching it to do
On 21/11/14 13:37, Jürgen Groß wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>> On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
> --- a/xen/include/public/arch-x86/xen.h
>>>
>>> On 21.11.14 at 14:37, wrote:
> On 11/21/2014 02:26 PM, Andrew Cooper wrote:
>> On 21/11/14 12:57, Juergen Gross wrote:
>>> On 11/21/2014 01:23 PM, Jan Beulich wrote:
>>> On 14.11.14 at 10:37, <"jgr...@suse.com".non-mime.internet> wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +
On Fri, 2014-11-21 at 09:28 +, Ian Campbell wrote:
> I think libvirt is wrong to specify an absolute path here, IMHO by
> default it should just specify "pygrub" and let libxl figure out the
> correct path. Jim, what do you think?
e.g. something like the following untested (but pretty obvious[
Hi Stefano,
On 20/11/2014 15:54, Stefano Stabellini wrote:
On Thu, 20 Nov 2014, Julien Grall wrote:
On 11/20/2014 11:02 AM, Julien Grall wrote:
Hi Stefano,
On 11/20/2014 10:53 AM, Stefano Stabellini wrote:
UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more
On 21/11/14 14:05, Ian Campbell wrote:
> On Fri, 2014-11-21 at 09:28 +, Ian Campbell wrote:
>> I think libvirt is wrong to specify an absolute path here, IMHO by
>> default it should just specify "pygrub" and let libxl figure out the
>> correct path. Jim, what do you think?
>
> e.g. something
An absolute age ago Michael posted a patch to allow pygrub to work with
split-partition layouts (i.e. those where the guests disk cfg refers to
xvda1, xvda2, etc rather than an xvda with a partition table). See
http://lists.xen.org/archives/html/xen-devel/2011-01/msg02076.html
(patch itself is belo
UIE being set can cause maintenance interrupts to occur when Xen writes
to one or more LR registers. The effect is a busy loop around the
interrupt handler in Xen
(http://marc.info/?l=xen-devel&m=141597517132682): everything gets stuck.
Signed-off-by: Stefano Stabellini
Acked-by: Ian Campbell
Re
On Fri, 2014-11-21 at 14:18 +, David Vrabel wrote:
> On 21/11/14 14:05, Ian Campbell wrote:
> > On Fri, 2014-11-21 at 09:28 +, Ian Campbell wrote:
> >> I think libvirt is wrong to specify an absolute path here, IMHO by
> >> default it should just specify "pygrub" and let libxl figure out th
Hi,
again a fallout from my "linear p2m list" tests:
Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system (it was 38000320-3800036f).
Instead of rejecting the operation Xen tried to perf
On 11/21/2014 06:12 AM, Wei Liu wrote:
On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote:
When parsing bitmap objects JSON parser will create libxl_bitmap
map of the smallest size needed.
This can cause problems when saved image file specifies CPU affinity.
For example, if 'vcpu_h
Il 21/11/2014 12:05, Fabio Fantoni ha scritto:
Il 20/11/2014 12:21, Fabio Fantoni ha scritto:
Il 13/11/2014 13:22, Fabio Fantoni ha scritto:
Il 13/11/2014 11:14, Fabio Fantoni ha scritto:
Il 19/09/2014 15:18, Fabio Fantoni ha scritto:
Il 12/09/2014 16:46, Fabio Fantoni ha scritto:
Il 08/07/2
On 11/21/2014 06:26 AM, Dario Faggioli wrote:
On Thu, 2014-11-20 at 16:27 -0500, Boris Ostrovsky wrote:
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 58df4f3..2a08bef 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -614,6 +614,13 @@ void libx
On 21/11/14 14:39, Juergen Gross wrote:
> Hi,
>
> again a fallout from my "linear p2m list" tests:
>
> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
> wrong device to the domain. The MMIO address was too large for a
> MFN of a 32-bit system (it was 38000320-3800036f).
>
>>> On 21.11.14 at 15:39, wrote:
> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
> wrong device to the domain. The MMIO address was too large for a
> MFN of a 32-bit system (it was 38000320-3800036f).
>
> Instead of rejecting the operation Xen tried to perform it resul
On 21/11/14 14:54, Jan Beulich wrote:
On 21.11.14 at 15:39, wrote:
>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>> wrong device to the domain. The MMIO address was too large for a
>> MFN of a 32-bit system (it was 38000320-3800036f).
>>
>> Instead of rejecting
On 11/21/2014 03:45 PM, Andrew Cooper wrote:
On 21/11/14 14:39, Juergen Gross wrote:
Hi,
again a fallout from my "linear p2m list" tests:
Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system (i
Currently we haven't exported vmemrange interface to libxl user.
Vmemranges are generated during domain build.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_internal.h |3 +++
1 file changed, 3 insertions(+)
diff --g
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 virt
This function gets the machine E820 map and sanitize it according to PV
guest configuration.
This will be used in later patch.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_x86.c | 31 ++-
1
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_types.idl |9 +
1 file changed, 9 insertions(+)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f7fc695..75855fb 100644
--- a/tools/li
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_arm.c |8
tools/libxl/libxl_x86.c |8
2 files changed, 16 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 448ac07.
One vmemrange is generated for each vnode. And for those guests who care
about machine E820 map, vmemranges are further split to accommodate
memory holes.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_arch.h |6 ++
Signed-off-by: Elena Ufimsteva
Signed-off-by: Wei Liu
Cc: Jan Beulich
---
xen/arch/x86/numa.c | 46 +-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 628a40a..d27c30f 100644
--- a/xen/ar
This vNUMA function (and future ones) is placed in a new file called
libxl_vnuma.c
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/Makefile |2 +-
tools/libxl/libxl_internal.h |5 ++
tools/libxl/libxl_vnuma.c|
Hi all
This patch series implements virtual NUMA support for both PV and HVM guest.
That is, admin can configure via libxl what virtual NUMA topology the guest
sees.
This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware
ballooning, hypervisor side) described in my previous ema
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxc/include/xc_dom.h |5 +++
tools/libxc/xc_dom_x86.c | 72 +++---
tools/libxc/xc_private.h |2 ++
3 files changed, 68 insertions(+)
On Fri, Nov 21, 2014 at 01:03:43PM +0100, Jan Beulich wrote:
> >>> On 21.11.14 at 12:50, wrote:
> > On November 21, 2014 2:51:33 AM EST, Jan Beulich wrote:
> > On 20.11.14 at 20:51, wrote:
> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
> >>struct hvm_pirq_dpci *pirq_
On Fri, Nov 21, 2014 at 01:51:24PM +0100, Sander Eikelenboom wrote:
>
> Friday, November 21, 2014, 12:50:16 PM, you wrote:
>
> > On November 21, 2014 2:51:33 AM EST, Jan Beulich wrote:
> > On 20.11.14 at 20:51, wrote:
> >>> @@ -669,7 +670,7 @@ static void hvm_dirq_assist(struct domain *d,
>
On Fri, Nov 21, 2014 at 11:08:37AM +0100, Juergen Gross wrote:
> Hi,
>
> during tests of my "linear p2m list" patches I stumbled over some
> WARNs issued during xl save and xl restore of a pv-domU with
> unpatched linux 3.18-rc5:
Boris had an patch for this I htink..
>
> during save I saw multip
On 11/21/2014 03:54 PM, Jan Beulich wrote:
On 21.11.14 at 15:39, wrote:
Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
wrong device to the domain. The MMIO address was too large for a
MFN of a 32-bit system (it was 38000320-3800036f).
Instead of rejecting the operati
On 11/21/2014 10:14 AM, Konrad Rzeszutek Wilk wrote:
On Fri, Nov 21, 2014 at 11:08:37AM +0100, Juergen Gross wrote:
Hi,
during tests of my "linear p2m list" patches I stumbled over some
WARNs issued during xl save and xl restore of a pv-domU with
unpatched linux 3.18-rc5:
Boris had an patch fo
On Mon, Nov 17, 2014 at 10:29:19AM +, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:41 +, Wei Liu wrote:
> > On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
> > > Avoid sending duplicated qmp commands and eliminate the confusing error
> > > messages like "Unable to add CPU: 0, i
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_dom.c | 71 +++
1 file changed, 71 insertions(+)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 74ea84b..73
And then returns low memory end, high memory end and mmio start to
caller.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxc/include/xenguest.h |7 ++
tools/libxc/xc_hvm_build_x86.c | 224 ++
Signed-off-by: Wei Liu
Cc: Jan Beulich
Cc: George Dunlap
---
tools/firmware/hvmloader/pci.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 4e8d803..d7ea740 100644
--- a/tools/firmware/hvmloader/pci.c
+++
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
tools/libxl/libxl_dom.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index bace1cb..5980d87
Changes:
1. Take care of function calls that can fail.
2. Use proper libxl error handling style.
3. Pass in build state instead of individual fields.
This is mechanical change in preparation for later patch.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena
Signed-off-by: Wei Liu
Cc: Jan Beulich
---
tools/firmware/hvmloader/acpi/acpi2_0.h | 53
tools/firmware/hvmloader/acpi/build.c | 68 +++
2 files changed, 121 insertions(+)
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h
b/tools/fi
Signed-off-by: Wei Liu
Cc: Jan Beulich
---
tools/firmware/hvmloader/acpi/acpi2_0.h |8 +++
tools/firmware/hvmloader/acpi/build.c | 36 +++
2 files changed, 44 insertions(+)
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h
b/tools/firmware/hvmloader/a
Libxc has more involvement in building vmemranges in HVM case. The
building of vmemranges is placed after xc_hvm_build returns, because it
relies on memory hole information provided by xc_hvm_build.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
On Thu, Nov 20, 2014 at 10:39:32AM +, Stefano Stabellini wrote:
> On Thu, 20 Nov 2014, Russell King - ARM Linux wrote:
> > On Tue, Nov 18, 2014 at 04:49:21PM +, Stefano Stabellini wrote:
> > > ping?
> >
> > Sending something which wants my attention _To:_ me is always a good idea :)
>
> I
Signed-off-by: Wei Liu
Cc: Jan Beulich
---
xen/include/public/hvm/hvm_info_table.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/xen/include/public/hvm/hvm_info_table.h
b/xen/include/public/hvm/hvm_info_table.h
index 36085fa..9d3f218 100644
--- a/xen/include/public/
On 21/11/14 15:04, Juergen Gross wrote:
> On 11/21/2014 03:45 PM, Andrew Cooper wrote:
>> On 21/11/14 14:39, Juergen Gross wrote:
>>> Hi,
>>>
>>> again a fallout from my "linear p2m list" tests:
>>>
>>> Trying to do PCI-passthrough with a 32-bit pv-domain I passed the
>>> wrong device to the domain
This patch includes configuration options parser and documentation.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
---
docs/man/xl.cfg.pod.5| 32 ++
tools/libxl/xl_cmdimpl.c | 151 ++
2
1 - 100 of 172 matches
Mail list logo
