Changes to V8:
* xl won't manage snapshots, that means it won't maintain json files,
won't maintain snapshot chain relationship, and then as a result
won't take care of deleting snapshot and listing snapshots.
* remove snapshot-delete and snapshot-list interface
* update snapshot-reve
Changes to V8:
* add a document for domain snapshot related terms, they will be
referred in later documents.
=
Terms
* Active domain: domain created and started
* Inactive domain: domain created but not started
* Domain s
Changes to V8:
- xl removes snapshot-delete/snapshot-list, keeps
snapshot-create/snapshot-revert only.
- libxl removes unnecessary domain snapshot functionality
libxl_domain_snapshot_create/delete/revert. Instead,
export disk snapshot functionality for xl/libvirt usage
in libxl/
Changes to V8:
* remove libxl_domain_snapshot_create/delete/revert API
* export disk snapshot functionality for both xl and libvirt usage
===
Libxl/libxlu Design
1. New Structures
libxl_disk_snapshot = Struct("disk_snaps
Changes to V8:
* add an overview document, so that one can has a overall look
about the whole domain snapshot work, limits, requirements,
how to do, etc.
=
Domain snapshot overview
1. Purpose
Domain snapshot is a syste
On 12/15/2014 01:05 PM, David Vrabel wrote:
On 11/12/14 18:04, Juergen Gross wrote:
Instead of manually list each hypercall in arch/x86/xen/xen-head.S
use the auto generated symbol list.
This also corrects the wrong address of xen_hypercall_mca which was
located 32 bytes higher than it should.
flight 32386 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
test-amd64-amd64-rump
> -Original Message-
> From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov]
> Sent: Monday, December 15, 2014 11:56 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: stefano.stabell...@eu.citrix.com; samuel.thiba...@ens-lyon.org
> Subject: Re: [PATCH 11/12] vTPM/TPM2: Bind group keys and s
> -Original Message-
> From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov]
> Sent: Monday, December 15, 2014 11:55 PM
> To: Xu, Quan; xen-devel@lists.xen.org
> Cc: stefano.stabell...@eu.citrix.com; samuel.thiba...@ens-lyon.org
> Subject: Re: [PATCH 09/12] vTPM/TPM2: Support '--tpm2' extr
Hello Ian,
On 15.12.2014 18:45, Ian Campbell wrote:
> On Mon, 2014-12-15 at 14:50 +, Ian Campbell wrote:
>> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
>>> I just noticed something strange:
>>>
#3 0x0040a684 in tdb_open (name=0xff >>> 0xff out of bounds
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do this via IPI since otherwise there is a (somewheat
theoretical) chance that between test and subsequent clearing
of last
Folks,
This Wednesday, December 17, is our fourth and FINAL Test Day
for the 4.5 release cycle (barring any changes which may result from
Wednesday's Test Day). Release Candidate 4 is available for
assessment today.
If you've held off testing the new release until it matures, delay no
longer! Te
On Mon, 2014-12-15 at 14:50 +, Ian Campbell wrote:
> On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> > I just noticed something strange:
> >
> > > #3 0x0040a684 in tdb_open (name=0xff > > 0xff out of bounds>, hash_size=0,
> > > tdb_flags=4254928, open_fla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
stable/for-linus-3.19-rc0b-tag
xen: additional features for 3.19-rc0
- - Linear p2m for x86 PV guests which simplifies the p2m code, improves
pe
On Thu, Dec 11, 2014 at 04:23:15PM +, Ian Campbell wrote:
> On Thu, 2014-12-11 at 16:16 +, Anthony PERARD wrote:
> > On Tue, Dec 09, 2014 at 03:56:02PM +, Ian Campbell wrote:
> > > On Tue, 2014-12-09 at 15:39 +, Anthony PERARD wrote:
> > > > The path to the pty of a Xen PV console i
On 12/15/2014 05:07 AM, Jan Beulich wrote:
On 12.12.14 at 22:20, wrote:
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
}
}
+static void vpmu_clear_last(void *arg)
+{
+struct vcpu *v = (struct vcpu *)arg;
Pl
On Wed, Dec 10, 2014 at 4:30 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 09, 2014 at 02:48:21PM +, Ian Campbell wrote:
>> On Tue, 2014-12-09 at 14:04 +, George Dunlap wrote:
>> > At the moment libxl unconditinally passes the underlying file format
>> > to qemu in the device string. How
On 12/14/2014 07:09 AM, Quan Xu wrote:
This series of patch enable the virtual Trusted Platform Module (vTPM)
subsystem for Xen on TPM 2.0.
Noted, functionality for a virtual guest operating system (a DomU) is still
TPM 1.2. The main modifcation is on vtpmmgr-stubdom. The challenge is that
TPM 2
>>> On 15.12.14 at 17:15, wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 16:22, wrote:
>> > On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >> >>> On 15.12.14 at 10:05, wrote:
>> >> > yes, definitely host RAM is the upper limit, and what I'm concerning
>> >> > here
>> >> > is
On 15/12/14 16:15, Stefano Stabellini wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
> On 15.12.14 at 16:22, wrote:
>>> On Mon, 15 Dec 2014, Jan Beulich wrote:
>>> On 15.12.14 at 10:05, wrote:
> yes, definitely host RAM is the upper limit, and what I'm concerning here
> is how t
On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 16:22, wrote:
> > On Mon, 15 Dec 2014, Jan Beulich wrote:
> >> >>> On 15.12.14 at 10:05, wrote:
> >> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> >> > is how to reserve (at boot time) or allocate (on-dem
Hi Stefano,
On 15/12/14 15:35, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> Use the new vgic interface to know which virtual PPI is free and use it
>> for the event channel code.
>>
>> At the DOM0 creation time, Xen still don't know which vIRQ will be free.
>> All the vI
Hi Stefano,
On 15/12/14 15:32, Stefano Stabellini wrote:
> On Fri, 12 Dec 2014, Julien Grall wrote:
>> +spin_lock_init(&d->arch.vgic.lock);
>
> you should probably explain in the commit message the reason why you are
> making changes to the vgic lock
Actually the domain vgic lock was never u
>>> On 15.12.14 at 16:22, wrote:
> On Mon, 15 Dec 2014, Jan Beulich wrote:
>> >>> On 15.12.14 at 10:05, wrote:
>> > yes, definitely host RAM is the upper limit, and what I'm concerning here
>> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
>> > resource, w/o collision w
On 12/15/2014 5:29 AM, Andrew Cooper wrote:
On 15/12/14 09:16, Jan Beulich wrote:
Avoid emitting an error message referring to an incorrect or corrupt
container file just because no entry was found for the running CPU.
Additionally switch the order of data validation and consumption in
cpu_requ
On 12/14/2014 07:09 AM, Quan Xu wrote:
[...]
+/*TPM 2.0 bind | TPM 1.x seal*/
+if (hw_is_tpm2()) {
+TPM2_disk_bind(dst, &sblob, sizeof(sblob));
+} else {
+dst->pcr_selection = src->seals[i].pcr_selection;
+memcpy(&dst->digest_release, &s
On 12/14/2014 07:09 AM, Quan Xu wrote:
Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
extra="--tpm2"
..
to launch vtpm-stubdom domain on TPM 2.0, ignore it on TPM 1.x. for
example,
vtpm-stubdom domain configuration on TPM 2.0:
kernel="/usr/lib/xen/boot/vtpmmgr-
Processing commands for x...@bugs.xenproject.org:
> create !
Created new bug #47 rooted at `<20141215154710.gc8...@zion.uk.xensource.com>'
Title: `Re: [PATCH for 4.5] libxl: Tell qemu to use raw format when using a
tapdisk'
> title it CDROM backend ignored and always treated as file
Set title for
flight 32361 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32361/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-sedf-pin 5 xen-bootfail pass in 32316
test-amd64-i386-rumpuserxen-i386 3
On Fri, 12 Dec 2014, Julien Grall wrote:
> Use the new vgic interface to know which virtual PPI is free and use it
> for the event channel code.
>
> At the DOM0 creation time, Xen still don't know which vIRQ will be free.
> All the vIRQ will be reserved when we parse the device tree. So allocate
>
On Fri, 12 Dec 2014, Julien Grall wrote:
> While it's easy to know which hardware IRQ is assigned to a domain, there
> is no way to know which IRQ is emulated by Xen for a specific domain.
>
> Introduce a bitmap to keep track of every vIRQ used by a domain. This
> will be used later to find free v
On Tue, Dec 09, 2014 at 02:04:19PM +, George Dunlap wrote:
[...]
> While preparing this patch, I also noticed that cdroms will ignore the
> backend parameter and treat everything as a file. This is a bug
create !
title it CDROM's backend ignored and always treated as file
thanks
On Mon, 15 Dec 2014, Jan Beulich wrote:
> >>> On 15.12.14 at 10:05, wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o collision with other PFN reservation usage (balloon
On Fri, 12 Dec 2014, David Vrabel wrote:
> On 12/12/14 13:17, Juergen Gross wrote:
> >
> >
> > As a first draft I'd suggest the following:
>
> Some rough thoughts below.
>
> > Option Selects Depends
> > ---
On Tue, 9 Dec 2014, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
>
>make xenconfig
>
> on both x86 and arm64 kernels. This also splits out the
> options which are available currently to be bui
On Mon, 2014-12-15 at 15:19 +0100, Philipp Hahn wrote:
> Hello Ian,
>
> On 15.12.2014 14:17, Ian Campbell wrote:
> > On Fri, 2014-12-12 at 17:58 +, Ian Campbell wrote:
> >> On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> >>> On 12.12.2014 17:56, Ian Campbell wrote:
> On Fri, 201
On Mon, 15 Dec 2014, Eric McLaughlin wrote:
> Hi Stefano,
>
> Would you be able to help us resolve the following issue?
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348442
I don't want to encourage third party closed source linux modules, but I
don't want to stand in your way ei
Hello Ian,
On 15.12.2014 14:17, Ian Campbell wrote:
> On Fri, 2014-12-12 at 17:58 +, Ian Campbell wrote:
>> On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
>>> On 12.12.2014 17:56, Ian Campbell wrote:
On Fri, 2014-12-12 at 17:45 +0100, Philipp Hahn wrote:
> On 12.12.2014 17:32
2014-12-12 16:01 GMT+00:00 Ian Campbell :
> On Fri, 2014-12-12 at 15:59 +, Ian Campbell wrote:
>> On Mon, 2014-12-08 at 15:47 +, Frediano Ziglio wrote:
>> > Hi,
>> > while I was porting D01 platform
>> > (https://wiki.linaro.org/Boards/D01) to Xen I wrote a small document
>> > trying to d
On 12/14/2014 09:58 AM, Wei Liu wrote:
> The original code always checked *boot which was in effect boot[0]. It
> should use boot[i].
In the future, when you do the investigation, just reference the commit
id that caused the regression. In this case it seems to be commit id
'547bd71a' (7/25/08
TDB provides us with a callback for this purpose. Use it in both
xenstored and xs_tdb_dump.
While at it make the existing log() macro tollerate memory failures.
Signed-off-by: Ian Campbell
---
tools/xenstore/xenstored_core.c | 39 +--
tools/xenstore/xs_tdb_
On Fri, 2014-12-12 at 17:58 +, Ian Campbell wrote:
> (adding Ian J who knows a bit more about C xenstored than me...)
>
> On Fri, 2014-12-12 at 18:20 +0100, Philipp Hahn wrote:
> > Hello Ian,
> >
> > On 12.12.2014 17:56, Ian Campbell wrote:
> > > On Fri, 2014-12-12 at 17:45 +0100, Philipp Ha
On 11/12/14 12:24, Ian Campbell wrote:
> These last two changes require that you cc the common serial maintainer,
> not just the ARM maintainers. In this case that means Keir, who I have
> CCd.
> ./scripts/get_maintainers.pl can help automate this.
The serial code lives in the "THE REST" category
On 11/12/14 18:04, Juergen Gross wrote:
> Instead of manually list each hypercall in arch/x86/xen/xen-head.S
> use the auto generated symbol list.
>
> This also corrects the wrong address of xen_hypercall_mca which was
> located 32 bytes higher than it should.
>
> Symbol addresses have been verif
Hello Luis,
On 09/12/14 23:35, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This lets you build a kernel which can support xen dom0
> or xen guests by just using:
>
>make xenconfig
>
> on both x86 and arm64 kernels. This also splits out the
> options which are available current
On 11/12/14 18:04, Juergen Gross wrote:
> Instead of manually list all hypervisor calls in arch/x86/xen/trace.c
> use the auto generated list.
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-
>>> On 15.12.14 at 12:38, wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
>
> Why are these changes here and not in arch/x86/xen/Makefile?
Because this needs to be done in a step that (afaict) has no hook
in the Xen-specifi
On 11/12/14 18:04, Juergen Gross wrote:
> The header include/xen/interface/xen.h doesn't contain all definitions
> from Xen's version of that header. Update it accordingly.
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen
On 11/12/14 18:04, Juergen Gross wrote:
> Today there are several places in the kernel which build tables
> containing one entry for each possible Xen hypercall. Create an
> infrastructure to be able to generate these tables at build time.
Does arm and arm64 need something similar? If so are the
On 15/12/14 09:16, Jan Beulich wrote:
> Avoid emitting an error message referring to an incorrect or corrupt
> container file just because no entry was found for the running CPU.
>
> Additionally switch the order of data validation and consumption in
> cpu_request_microcode()'s first loop, and also
>>> On 15.12.14 at 12:16, wrote:
> I expect to have everything mapped into the available mapping space,
> and is asking for suggestions what's the best way to find and reserve
> available PFNs in a way not conflicting with other usages (either
> virtualization features like ballooning that you men
>>> On 15.12.14 at 11:44, wrote:
> isal 20140926-1 in Debian Jessie is rather vocal about
> tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
> Control Method should be made Serialized (due to creation of
> named objects within)
> a slew of:
> Object is
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 15, 2014 5:23 PM
>
> >>> On 15.12.14 at 10:05, wrote:
> > yes, definitely host RAM is the upper limit, and what I'm concerning here
> > is how to reserve (at boot time) or allocate (on-demand) such large PFN
> > resource, w/o
On Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote:
> > Hi Konrad,
> >
> > This doesn't seem to be applied yet, nor does it seem to have a
> > release-(N)ACK
> > from you ?
>
> Hm, Stefano:
>
> - Is this a regression?
I don't
On 12/12/2014 06:29 PM, David Vrabel wrote:
On 12/12/14 13:17, Juergen Gross wrote:
As a first draft I'd suggest the following:
Some rough thoughts below.
Option Selects Depends
--
On 12/15/2014 10:18 AM, Ian Campbell wrote:
> On Sat, 2014-12-13 at 17:06 +, Wei Liu wrote:
>> On Thu, Dec 11, 2014 at 04:45:09PM +, George Dunlap wrote:
>>> On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang wrote:
If we use blktap2, the correct file should be blktap device
not the p
On 11/12/14 15:12, Christopher S. Aker wrote:
> Xen: 4.4.2-pre (28573:f6f6236af933) + xsa111, xsa112, xsa114
> Dom0: 3.17.4
>
> Things go badly after a day or four. We've hit this on a number of
> previously healthy hosts, since moving from 3.10.x dom0 to 3.17.4:
>
> printk: 5441 messages suppr
On Sun, 2014-12-14 at 21:09 +0530, Galla Rao wrote:
> True it is not on Xen, it is on solaris platform
>
>
> As SRIOV (PCIe) spec is same on all platforms, the feature
> implementation
> should not change
>
>
> May be not an appropriate group for posting this query.
If you aren't using Xen the
On Fri, 12 Dec 2014, Jie Shen wrote:
> Hello Vincent and Stefano,
Hello Jie,
please ask libxl related questions on the xen mailing list
(xen-devel@lists.xen.org), CC'ed.
> I am working on a project to change xen's code.
>
> Unfortunately I can not find the MACRO def :
> such as :
>
> LIBXL_SC
On Mon, 2014-12-15 at 10:56 +, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's s
flight 32379 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32379/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 26303
build-i386
On 12/12/2014 05:44 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Dec 12, 2014 at 02:17:27PM +0100, Juergen Gross wrote:
Hi,
This is a design proposal for a rework of the config options on the
Linux kernel which are related to Xen.
The need to do so arose from the fact that it is currently not
poss
flight 32377 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32377/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 32194
build-amd64
On Mon, Dec 15, 2014 at 10:52:40AM +, David Vrabel wrote:
> On 27/10/14 12:33, Wei Liu wrote:
> >
> > ### Periodically exchange normal size pages with huge pages
> >
> > Worker thread wakes up periodically to check if there are enough pages
> > in normal size page queue to coalesce into a hug
samuel.thiba...@ens-lyon.org said:
> > From: Martin Lucina
> > Date: Thu, 4 Dec 2014 14:33:53 +0100
> > Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx
> >
> > In network_rx() we must push the same amount of requests back onto the
> > ring in the second loop that we consu
In commit d36a3734a ("xl: fix migration failure with xl migrate
--debug"), message is printed to stderr for both debug mode
and dryrun mode. That caused rdname() in xendomains fails to parse
domain name since it's expecting input from xl's stdout.
So this patch separates those two cases. If xl is
On 27/10/14 12:33, Wei Liu wrote:
>
> ### Periodically exchange normal size pages with huge pages
>
> Worker thread wakes up periodically to check if there are enough pages
> in normal size page queue to coalesce into a huge page. If so, it will
> try to exchange that huge page into a number of n
On Sat, 2014-12-13 at 13:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Dec 13, 2014 at 06:42:09PM +, Wei Liu wrote:
> > On Sat, Dec 13, 2014 at 01:37:16PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Sat, Dec 13, 2014 at 04:54:05PM +, Wei Liu wrote:
> > > > In commit d36a3734a ("xl: fix
On Sat, 2014-12-13 at 16:54 +, Wei Liu wrote:
> In commit d36a3734a ("xl: fix migration failure with xl migrate
> --debug"), message is printed to stderr for both debug mode
> and dryrun mode. That caused rdname() in xendomains fails to parse
> domain name since it's expecting input from xl's s
isal 20140926-1 in Debian Jessie is rather vocal about
tools/firmware/hvmloader/acpi. See below. Essentially, a few of these:
Control Method should be made Serialized (due to creation of
named objects within)
a slew of:
Object is not referenced ^ (Name is within method [_CR
flight 32374 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/32374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 31241
build-i386-pvops
On Sat, 2014-12-13 at 17:06 +, Wei Liu wrote:
> On Thu, Dec 11, 2014 at 04:45:09PM +, George Dunlap wrote:
> > On Mon, Sep 22, 2014 at 6:59 AM, Wen Congyang wrote:
> > > If we use blktap2, the correct file should be blktap device
> > > not the pdev_path.
> > >
> > > Signed-off-by: Wen Cong
>>> On 14.12.14 at 04:20, wrote:
> - If using virsh, the domain can be created while dom0 is still ballooning
> down. This results in CPU soft lockups/performance degradation across the
> entire host. (When creating a very large domain, the soft lockups can be
> severe enough to kill the machin
On Sun, 2014-12-14 at 14:58 +, Wei Liu wrote:
> The original code always checked *boot which was in effect boot[0]. It
> should use boot[i].
>
> Signed-off-by: Wei Liu
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
>>> On 12.12.14 at 22:20, wrote:
> --- a/xen/arch/x86/hvm/vpmu.c
> +++ b/xen/arch/x86/hvm/vpmu.c
> @@ -247,10 +247,32 @@ void vpmu_initialise(struct vcpu *v)
> }
> }
>
> +static void vpmu_clear_last(void *arg)
> +{
> +struct vcpu *v = (struct vcpu *)arg;
Please drop this pointless cas
On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote:
Ping again. This issue has resurfaced in the Debian packaging of the 4.5
rcs. I think we should fix this for 4.5, the risks are minimal.
> It uses libxl_defbool_set and must therefore be linked against the
> right library.
>
> Spotted by dpk
>>> On 12.12.14 at 23:48, wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
On Sun, 2014-12-14 at 07:09 -0500, Quan Xu wrote:
> This series of patch enable the virtual Trusted Platform Module (vTPM)
> subsystem for Xen on TPM 2.0.
Please can you investigate the --thread option to "git send-email"
and/or "git format-patch", such that all of the mails appear as replies
to t
On Fri, 2014-12-12 at 16:49 -0600, Jie Shen wrote:
> Hello Gurus,
>
>
> I am working on a project to change code of xen,
> Unfortunately I can not find the macro def of : LIBXL_SCHEDULER_
Check tools/libxl/{libxl_types.idl,idl.py,gentypes.py,idl.txt}
Ian.
>>> On 15.12.14 at 10:05, wrote:
> yes, definitely host RAM is the upper limit, and what I'm concerning here
> is how to reserve (at boot time) or allocate (on-demand) such large PFN
> resource, w/o collision with other PFN reservation usage (ballooning
> should be fine since it's operating existi
Avoid emitting an error message referring to an incorrect or corrupt
container file just because no entry was found for the running CPU.
Additionally switch the order of data validation and consumption in
cpu_request_microcode()'s first loop, and also check the types of
skipped blocks in container
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 15, 2014 4:45 PM
>
> >>> On 15.12.14 at 07:25, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >>> On 12.12.14 at 08:24, wrote:
> >> > - how is BFN or unused address (what do you mean by address here?)
> >> >
On Fri, Dec 12, 2014 at 03:02:33PM +, Andrew Cooper wrote:
> On 12/12/14 12:27, Chao Peng wrote:
> > Hi all, we plan to bring Intel CAT into XEN. This is the initial
> > design for that. Comments/suggestions are welcome.
> >
>
> Fantastic - this is a very clear and well presented document. In
>>> On 15.12.14 at 07:25, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >>> On 12.12.14 at 08:24, wrote:
>> > - how is BFN or unused address (what do you mean by address here?)
>> > allocated? does it need present in guest physical memory at boot time,
>> > or just finding some holes
>>> On 12.12.14 at 17:41, wrote:
> On Fri, Dec 12, 2014 at 09:45:17AM +, Jan Beulich wrote:
>> >>> On 11.12.14 at 20:41, wrote:
>> > On Thu, Dec 11, 2014 at 03:38:39PM +, Jan Beulich wrote:
>> >> >>> On 11.12.14 at 16:18, wrote:
>> >> > A proper fix would be to automatically adjust based
85 matches
Mail list logo
