>>> On 14.01.15 at 19:39, wrote:
> On Wed, Jan 14, 2015 at 09:06:37AM +, Jan Beulich wrote:
>> >>> On 13.01.15 at 21:43, wrote:
>> > On 01/13/2015 02:27 PM, Konrad Rzeszutek Wilk wrote:
>> >> I was wondering if there would be any plans for configure.ac
>> >> (or the m4 scripts) to have an --e
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, January 15, 2015 4:43 AM
>
> On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: Wednesday, January 14, 2015 12:46 AM
> > >
> > >
>
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Wednesday, January 14, 2015 8:23 PM
>
> On 01/14/2015 12:14 PM, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Wednesday, January 14, 201
>>> On 14.01.15 at 18:25, wrote:
> I modify my code and here are some output examples:
>
> (XEN) Domain 1 (total: 768064):
> (XEN) Node 0: 768064
> (XEN) 2 vnodes, 20 vcpus, guest physical layout:
> (XEN) 0: pnode 0 vcpus 0-9
> (XEN) - 5dc00
>>> On 14.01.15 at 18:35, wrote:
> On 01/14/2015 03:28 AM, Tamas K Lengyel wrote:
>> At the mem_access trap point you can swap in an altp2m where the
>> gfn->mfn mapping is the one where the breakpoints are hidden,
>> singlestep, then swap the original p2m back. While this approach still
>> has so
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Thursday, January 15, 2015 2:22 AM
>
> On 01/14/2015 02:42 PM, Jan Beulich wrote:
> On 14.01.15 at 13:29, wrote:
> >> On 01/14/2015 08:06 AM, Tian, Kevin wrote:
> >>> We discussed earlier there are two reasons that some confl
>>> On 14.01.15 at 22:19, wrote:
> So when Xen allocate memory to a PV guest with 256MB memory and 4KB
> page size (i.e., 2^16 memory pages), Xen will allocate 2^16 continuous
> memory pages to this guest since the maximum continuous memory pages
> Xen allocates to PV guest is 1024*1024.
Provided
>>> On 14.01.15 at 19:29, wrote:
> Just to be clear -- what we're talking about here is that at the
> do_domain_create() level (called by libxl_domain_create_new()), it will
> take a list of pci devices, and the rmrr list above (including "host"
> and individual ranges), and generate a list of RMR
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 11:08 PM
>
> >>> On 14.01.15 at 13:17, wrote:
> > On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
> >> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> >> hard conflicts
> >
> > OOI what i
>>> On 14.01.15 at 21:42, wrote:
> On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
>> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> > Sent: Wednesday, January 14, 2015 12:46 AM
>> >
>> >
>> > Perhaps an easier way of this is to use the existing
>> > mechanism we h
On Tue, Jan 06, 2015 at 10:29:18AM +, Andrew Cooper wrote:
> On 06/01/15 10:09, Chao Peng wrote:
> > On Mon, Jan 05, 2015 at 12:39:42PM +, Wei Liu wrote:
> >> On Tue, Dec 23, 2014 at 04:54:39PM +0800, Chao Peng wrote:
> >> [...]
> >>> +static int libxl__psr_cmt_get_mem_bandwidth(libxl__gc *
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the p2m code to replace ACCESS_ONCE with READ_ONCE.
Commit a91ed664749c ("kernel: tighten rules for ACCESS ONCE") results in
sparse warnings like "Using plain integer as NULL pointer" - Let's add a
type cast to the dummy assignment.
To avoid warnings lik "sparse: warning: cast to restricted __hc32" we also
use __force on that cast.
Fixes: a91ed6647
Folks,
fyi, this is my current patch queue for the next merge window. It
does contain a patch that will disallow ACCESS_ONCE on non-scalar
types.
The tree is part of linux-next and can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git linux-next
Christian Borntraeg
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Fixup gup_pmd_range.
Signed-off-by: Christian Borntraeger
From: Guenter Roeck
Commit a91ed664749c ("kernel: tighten rules for ACCESS ONCE") results in a
compile failure for sh builds with CONFIG_X2TLB enabled.
arch/sh/mm/gup.c: In function 'gup_get_pte':
arch/sh/mm/gup.c:20:2: error: invalid initializer
make[1]: *** [arch/sh/mm/gup.o] Error 1
Replace
Now that all non-scalar users of ACCESS_ONCE have been converted
to READ_ONCE or ASSIGN once, lets tighten ACCESS_ONCE to only
work on scalar types.
This variant was proposed by Alexei Starovoitov.
Signed-off-by: Christian Borntraeger
Reviewed-by: Paul E. McKenney
---
include/linux/compiler.h |
commit 78bff1c8684f ("x86/ticketlock: Fix spin_unlock_wait() livelock")
introduced another ACCESS_ONCE case in x86 spinlock.h.
Change that as well.
Signed-off-by: Christian Borntraeger
Cc: Oleg Nesterov
---
arch/x86/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the ppc/hugetlbfs code to replace ACCESS_ONCE with
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Change the ppc/kvm code to replace ACCESS_ONCE with READ_O
On 01/15/2015 03:57 PM, Olaf Hering wrote:
> On Thu, Jan 15, Wen Congyang wrote:
>
>> Commit 1166ecf7 disables optimization. But python's build
>> process may use CFLAGS -Wp,-D_FORTIFY_SOURCE=2, and suppose
>> the 3rd party python modules to use. The macro _FORTIFY_SOURCE
>> requires compiling wit
On Thu, Jan 15, Wen Congyang wrote:
> Xen doesn't use the macro _FORTIFY_SOURCE, so it only affects python
> modules now.
It does if it is passed via global CFLAGS, like the RPM_OPT_FLAGS from a
rpm package build.
Olaf
___
Xen-devel mailing list
Xen-d
On Jan 12, 5:25pm, Daniel De Graaf wrote:
} Subject: Re: [Xen-devel] Architecture for dom0 integrity measurements.
Hi Daniel, thanks for taking time to respond. Hope your week is going
well.
> >> -Original Message-
> >> From: xen-devel-boun...@lists.xen.org
> >> [mailto:xen-devel-boun..
On 01/15/2015 05:21 PM, Olaf Hering wrote:
> On Thu, Jan 15, Wen Congyang wrote:
>
>> Xen doesn't use the macro _FORTIFY_SOURCE, so it only affects python
>> modules now.
>
> It does if it is passed via global CFLAGS, like the RPM_OPT_FLAGS from a
> rpm package build.
Yes, I don't consider such
On 01/15/2015 09:58 AM, Christian Borntraeger wrote:
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates) step
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Cha
On Wed, 2015-01-14 at 16:56 +, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [OSSTEST PATCH] make-flight: reorganize
> scheduling related test jobs"):
> > On Mon, 2015-01-12 at 16:52 +, Ian Jackson wrote:
> > > This looks plausible but can you include the output of a diff between
> > >
Signed-off-by: Wen Congyang
---
tools/Rules.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 962a743..0a54bf1 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -57,6 +57,8 @@ SHLIB_libxenvchan = -Wl,-rpath-link=$(XEN_LIBVCHAN)
ifeq ($(debug),y)
On Wed, 2015-01-14 at 16:58 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: provide xenlight.pc"):
> > On Fri, 2015-01-09 at 14:32 +, Wei Liu wrote:
> > > A pkg-config file for libxl. It also contains two variables
> > > (xenfirmwaredir and libexec_bin) so that tools that a
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 15, 2015 4:38 PM
>
> >>> On 14.01.15 at 19:29, wrote:
> > Just to be clear -- what we're talking about here is that at the
> > do_domain_create() level (called by libxl_domain_create_new()), it will
> > take a list of pci de
On Wed, 2015-01-14 at 13:39 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 14, 2015 at 09:06:37AM +, Jan Beulich wrote:
> > >>> On 13.01.15 at 21:43, wrote:
> > > On 01/13/2015 02:27 PM, Konrad Rzeszutek Wilk wrote:
> > >> I was wondering if there would be any plans for configure.ac
> > >>
flight 33410 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33410/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
Tests which did n
On Wed, 2015-01-14 at 18:14 +, George Dunlap wrote:
> On 01/14/2015 03:43 PM, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
> >> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> > Host BIOSes are generally large compared to the guest BIOS, but with the
> >
>>> On 15.01.15 at 10:36, wrote:
> We'll need to make that skeleton ready first. Then regarding to config
> interface, how about making some simplification by only considering
> statically-assigned device and hotplug now (leaving migration to future
> based on necessity, and extending that doesn
On Wed, 2015-01-14 at 20:45 -0500, Marcos E. Matsunaga wrote:
> Hi Folks,
>
> We have a daily build process for xen 4.5 and while checking the last
> few days build, I found an error that was introduced by
>
> 1166ecf tools/Rules.mk: Don't optimize debug builds; add macro debugging
> informatio
On Thu, 2015-01-15 at 11:31 +0800, Zhenzhong Duan wrote:
> Hi Maintainers,
>
>
> We are facing issue collecting coredump using the xm dump mechanism
> in Dom0.
>
> We face couple of such issues daily, where the VMs panic s and the SA
> team is supposed to collect the core.
>
> The actual probl
On Wed, 2015-01-14 at 16:57 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/15 16:33, Ian Campbell wrote:
> > On Thu, 2014-09-11 at 09:43 +0100, Ian Campbell wrote:
> >> On Wed, 2014-09-10 at 11:54 -0700, Julien Grall wrote:
> >>> Hi Ian,
> >>>
> >>> On 10/09/14 02:46, Ian Campbell wrote:
>
El 02/01/15 a les 17.20, Jan Beulich ha escrit:
Roger Pau Monné 12/22/14 7:44 PM >>>
>> No, the same box I have with Linux doesn't use the IO-APIC re-route
>> quirk. I've also tested this on different hardware and when using
>> FreeBSD with the new IO APIC Ack method I always end up in this st
On 15/01/15 08:14, Jan Beulich wrote:
On 14.01.15 at 18:25, wrote:
>> I modify my code and here are some output examples:
>>
>> (XEN) Domain 1 (total: 768064):
>> (XEN) Node 0: 768064
>> (XEN) 2 vnodes, 20 vcpus, guest physical layout:
>> (XEN) 0: pnode 0 vcpus 0-9
>> (XEN
> There are ways of avoiding the
> single-step too, although I don't think that falls within the scope
> of this conversation.
>
> Ed
I would be very interested in knowing how we can avoid the singlestep
phase. Are you envisioning using this with a split-TLB? IMHO this is a
pretty critical compone
On 15/01/15 08:58, Christian Borntraeger wrote:
> ACCESS_ONCE does not work reliably on non-scalar types. For
> example gcc 4.6 and 4.7 might remove the volatile tag for such
> accesses during the SRA (scalar replacement of aggregates) step
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
>
At 12:58 + on 14 Jan (1421236725), Andrew Cooper wrote:
> On 13/01/15 20:10, Julien Grall wrote:
> > The code to initialize the grant table in libxc uses
> > xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
> > frame and to initialize it.
> >
> > This solution has two major
On Wed, 14 Jan 2015, 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 bu
On Mon, Jan 12, 2015 at 06:09:33PM +, Stefano Stabellini wrote:
> Hi all,
> I would like to request a backport of the following commit:
>
>
> commit a4dba130891271084344c12537731542ec77cb85
> Author: Stefano Stabellini
> Date: Fri Nov 21 11:07:39 2014 +
>
> xen/arm/arm64: introduc
Am 15.01.2015 um 11:43 schrieb David Vrabel:
> On 15/01/15 08:58, Christian Borntraeger wrote:
>> ACCESS_ONCE does not work reliably on non-scalar types. For
>> example gcc 4.6 and 4.7 might remove the volatile tag for such
>> accesses during the SRA (scalar replacement of aggregates) step
>> (http
Ian Campbell writes ("Re: [OSSTEST PATCH] make-flight: reorganize scheduling
related test jobs"):
> On Wed, 2015-01-14 at 16:56 +, Ian Jackson wrote:
> > That's what I meant, exactly. But looking at it shows that it would
> > benefit from being the output of
> > ./mg-show-flight-runvars sta
On Thu, 2015-01-15 at 11:10 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH] make-flight: reorganize scheduling
> related test jobs"):
> > On Wed, 2015-01-14 at 16:56 +, Ian Jackson wrote:
> > > That's what I meant, exactly. But looking at it shows that it would
> > > ben
Hi Sander,
It really cost me some time to understand HVM, PVH, Dom0, PV and
read Xen interrupt related code:( Now I have basic understanding of
related staffs. The patch for previous issue is actually wrong and
I'm working on another fixes for it. I will handle this issue once
getting done
Otherwise the last thing printed is "(XE" or something.
In line with x86 also disable the watchdog and spin debugging.
Signed-off-by: Ian Campbell
---
xen/arch/arm/shutdown.c |4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
index 4988b
Wen Congyang writes ("[PATCH v2] Fix building error"):
> ifeq ($(debug),y)
> # Disable optimizations and enable debugging information for macros
> CFLAGS += -O0 -g3
> +# _FORTIFY_SOURCE requires compiling with optimization
> +CFLAGS += -Wp,-U_FORTIFY_SOURCE
I'm not entirely convinced about this
On Thu, Jan 15, 2015 at 9:36 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, January 15, 2015 4:38 PM
>>
>> >>> On 14.01.15 at 19:29, wrote:
>> > Just to be clear -- what we're talking about here is that at the
>> > do_domain_create() level (called by lib
On Thu, Jan 15, 2015 at 10:05 AM, Ian Campbell wrote:
> On Wed, 2015-01-14 at 18:14 +, George Dunlap wrote:
>> On 01/14/2015 03:43 PM, Ian Campbell wrote:
>> > On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
>> >> Actually, I was just thinking about this -- I'm not really sure why we
>
Hi Ian,
On 15/01/15 10:26, Ian Campbell wrote:
> I'm looking into the vtimer masking and ctxt switching the irq state
> now, once I've got that going exposing the ptimer directly to guests
> ought to be pretty simple.
I don't think we can expose directly the physical timer to the guest.
If the g
The -initrd and -append parameters should only be supplied to QEMU iff
-kernel parameter is present, because that's how QEMU works.
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Chunyan Liu
---
tools/libxl/libxl_dm.c | 11 ++-
1 file changed, 6
On Thu, 2015-01-15 at 12:27 +, Julien Grall wrote:
> Hi Ian,
>
> On 15/01/15 10:26, Ian Campbell wrote:
> > I'm looking into the vtimer masking and ctxt switching the irq state
> > now, once I've got that going exposing the ptimer directly to guests
> > ought to be pretty simple.
>
> I don't
Hi Ian,
On 15/01/15 11:22, Ian Campbell wrote:
> Otherwise the last thing printed is "(XE" or something.
>
> In line with x86 also disable the watchdog and spin debugging.
>
> Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
> ---
> xen/arch/arm/shutdown.c |4
> 1 file changed
On Thu, 2015-01-15 at 12:57 +, Julien Grall wrote:
> Hi Ian,
>
> On 15/01/15 11:22, Ian Campbell wrote:
> > Otherwise the last thing printed is "(XE" or something.
> >
> > In line with x86 also disable the watchdog and spin debugging.
> >
> > Signed-off-by: Ian Campbell
>
> Reviewed-by: Ju
Commit b81975eade8c ("x86, irq: Clean up irqdomain transition code")
breaks xen IRQ allocation because xen_smp_prepare_cpus() doesn't invoke
setup_IO_APIC(), so no irqdomains created for IOAPICs and
mp_map_pin_to_irq() fails at the very beginning.
Currently Xen Domain0 has special treatment for AC
There's no use of gsi_override related logic anymore, so kill code
related to gsi_override.
Signed-off-by: Jiang Liu
---
arch/x86/pci/xen.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 6e5e89c3c644..a73
On 15/01/15 10:45, Tim Deegan wrote:
> At 12:58 + on 14 Jan (1421236725), Andrew Cooper wrote:
>> On 13/01/15 20:10, Julien Grall wrote:
>>> The code to initialize the grant table in libxc uses
>>> xc_domain_maximum_gpfn() + 1 to get a guest pfn for mapping the grant
>>> frame and to initialize
On 15/01/15 13:14, Andrew Cooper wrote:
> For things like grant tables, the toolstack is already capable of using
> add_to_physmap to make the pages mappable, but this is inefficient and
> possibly interferes with the guest physical layout. I propose a short
> circuit of this which allows the tool
Hi Ian,
On 14/01/15 12:42, Julien Grall wrote:
> On 14/01/15 12:28, Ian Campbell wrote:
>> On Tue, 2015-01-13 at 20:33 +, Julien Grall wrote:
>>> On 13/01/15 15:55, Ian Campbell wrote:
On Fri, 2014-12-12 at 14:43 +, Julien Grall wrote:
> This help for guest interrupts debugging. I
On Thu, 2015-01-15 at 13:27 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/15 12:42, Julien Grall wrote:
> > On 14/01/15 12:28, Ian Campbell wrote:
> >> On Tue, 2015-01-13 at 20:33 +, Julien Grall wrote:
> >>> On 13/01/15 15:55, Ian Campbell wrote:
> On Fri, 2014-12-12 at 14:43 +,
Hi,
On 17/12/14 17:52, Andrew Cooper wrote:
> On 17/12/14 17:10, Jan Beulich wrote:
> Julien Grall 12/17/14 1:55 PM >>>
>>> On 17/12/14 10:05, Jan Beulich wrote:
>> On 16.12.14 at 21:08, wrote:
> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
Any reason not to simply use
On Wed, 2015-01-14 at 12:53 +, Julien Grall wrote:
> Minor updates to the documentation in xen/include/public/arch-arm.h:
> - Comments coding style fix
> - Typoes
> - Update the list of supported hypercalls by ARM
> - Remove uncessary comment about 64bit.
"unnecessary"
> Signe
On Thu, 2015-01-15 at 12:29 +, Wei Liu wrote:
> The -initrd and -append parameters should only be supplied to QEMU iff
> -kernel parameter is present, because that's how QEMU works.
What do you think of catching this e.g. in the setdefault function and
warning or erroring in this case?
> Sign
Hi,
On 15/01/15 13:48, Ian Campbell wrote:
> On Wed, 2015-01-14 at 12:53 +, Julien Grall wrote:
>> Minor updates to the documentation in xen/include/public/arch-arm.h:
>> - Comments coding style fix
>> - Typoes
>> - Update the list of supported hypercalls by ARM
>> - Remove unc
On Thu, 2015-01-15 at 13:53 +, Julien Grall wrote:
> Hi,
>
> On 15/01/15 13:48, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 12:53 +, Julien Grall wrote:
> >> Minor updates to the documentation in xen/include/public/arch-arm.h:
> >> - Comments coding style fix
> >> - Typoes
> >>
Thanks Ian,
I definitely missed that.
On 01/15/2015 05:18 AM, Ian Campbell wrote:
On Wed, 2015-01-14 at 20:45 -0500, Marcos E. Matsunaga wrote:
Hi Folks,
We have a daily build process for xen 4.5 and while checking the last
few days build, I found an error that was introduced by
1166ecf tool
>>> On 14.01.15 at 12:37, wrote:
On 14.01.15 at 12:22, wrote:
>> On 14/01/15 10:52, Jan Beulich wrote:
>> On 14.01.15 at 11:33, wrote:
flight 33399 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33399/
Regressions :-(
Tests which
flight 33414 xen-4.5-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33414/
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-libvirt 9 gue
Make vtpm-stubdom domain compatible to launch on TPM 1.x / TPM 2.0.
Add:
..
extra="tpm2=1"
..
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-stubdom.gz"
memory=16
disk=["file:/v
'vtpmmgr on TPM 2.0'
Signed-off-by: Quan Xu
---
docs/misc/vtpmmgr.txt | 155 +-
1 file changed, 154 insertions(+), 1 deletion(-)
diff --git a/docs/misc/vtpmmgr.txt b/docs/misc/vtpmmgr.txt
index 026c52b..d4f756c 100644
--- a/docs/misc/vtpmmgr.txt
+
TPM2_CreatePrimary is used to create a Primary Object under one of
the Primary Seeds or a Temporary Object under TPM_RH_NULL. The command
uses a TPM2B_PUBLIC as a template for the object to be created. The
command will create and load a Primary Object. The sensitive area is
not returned. Any type o
Add TPM 2.0 data structures on Trusted Platform Module Library Part 2:
Structures and Trust Platform Module Library Part 3: Commands.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/tpm2_types.h | 978 +++
1 file changed, 978 insertions(+)
create mode 100644 s
call the TPM 2.0 various registers that allow communication between
the TPM 2.0 and platform hardware and software. TPM2_SelfTest causes
the TPM 2.0 to perform a test of its capabilities.
Signed-off-by: Quan Xu
---
extras/mini-os/include/tpm_tis.h | 1 +
extras/mini-os/tpm_tis.c | 156
TPM2_Create is used to create an object that can be loaded into a
TPM using TPM2_Load(). If the command completes successfully, the
TPM will create the new object and return the object’s creation.
data (creationData), its public area (outPublic), and its encrypted
sensitive area (outPrivate). Prese
These data is for the Mini-os to access TPM 2.0 hardware.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/vtpmmgr.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h
index 2d9d153..0d0c604 100644
--- a/stubdom/vtpmmgr/vtpmmgr.h
+++ b/st
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.0 is not backward compatible with TPM 1.
Bind data with TPM2_RSA_Encrypt, which performs RSA encryption using
the indicated padding scheme according to PKCS#1v2.1(PKCS#1). If the
scheme of keyHandle is TPM_ALG_NULL, then the caller may use inScheme
to specify the padding scheme.
Unbind data with TPM2_RSA_Decrypt, which performs RSA decryp
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/init.c | 34 ++
stubdom/vtpmmgr/tpm2_types.h | 2 ++
stubdom/vtpmmgr/vtpmmgr.h| 1 +
3 files changed, 37 insertions(+)
diff --git a/stubdom/vtpmmgr/init.c b/stubdom/vtpmmgr/init.c
index 980f622..1506735 100644
Accept commands from the vtpm-stubdom domains via the mini-os TPM
backend driver. The vTPM manager communicates directly with hardware
TPM 2.0 using the mini-os tpm2_tis driver.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/init.c| 109 ++
stubdom/vtp
Add TPM 2.0 data structure marshal for packing and unpacking TPM
2.0 data structures.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/tpm2_marshal.h | 673 +
1 file changed, 673 insertions(+)
create mode 100644 stubdom/vtpmmgr/tpm2_marshal.h
diff --git a/stub
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/disk_read.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/stubdom/vtpmmgr/disk_read.c b/stubdom/vtpmmgr/disk_read.c
index 33aacdd..e9dc20f 100644
--- a/stubdom/vtpmmgr/disk_read.c
+++ b/stubdom/vtpmmgr/disk_read.c
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/disk_write.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/stubdom/vtpmmgr/disk_write.c b/stubdom/vtpmmgr/disk_write.c
index 4c825c5..ab15a9a 100644
--- a/stubdom/vtpmmgr/disk_write.c
+++ b/stubdom/vtpmmgr/disk_write.
These TPM 2.0 Exposed APIs for the Mini-os to access TPM 2.0
hardware.
Signed-off-by: Quan Xu
---
stubdom/vtpmmgr/Makefile | 2 +-
stubdom/vtpmmgr/tpm2.c | 455 +++
stubdom/vtpmmgr/tpm2.h | 104 +++
3 files changed, 560 insertions(+), 1 d
2015-01-15 3:23 GMT-05:00 Jan Beulich :
On 14.01.15 at 22:19, wrote:
>> So when Xen allocate memory to a PV guest with 256MB memory and 4KB
>> page size (i.e., 2^16 memory pages), Xen will allocate 2^16 continuous
>> memory pages to this guest since the maximum continuous memory pages
>> Xen
Wei
Are this series of patch in one thread? Thanks.
-Quan
> -Original Message-
> From: Xu, Quan
> Sent: Thursday, January 15, 2015 5:22 PM
> To: xen-devel@lists.xen.org; dgde...@tycho.nsa.gov
> Cc: ian.campb...@citrix.com; ian.jack...@eu.citrix.com; jbeul...@suse.com;
> k...@xen.org; t
c/s 3f8e22de7 "x86 hvm: Allow HPET to be configured as a per-domain config
option" introduced the parameter to conditionally enable the HPET.
However, having the check in hpet_range() does not have the intended effect.
As currently implemented, when the HPET is disabled, the range is not claimed
a
On Thu, Jan 15, 2015 at 01:50:27PM +, Ian Campbell wrote:
> On Thu, 2015-01-15 at 12:29 +, Wei Liu wrote:
> > The -initrd and -append parameters should only be supplied to QEMU iff
> > -kernel parameter is present, because that's how QEMU works.
>
> What do you think of catching this e.g.
>>> On 15.01.15 at 15:14, wrote:
> But I think I made a wrong assumption above regarding the
> guest size: test-amd64-i386-xl-win7-amd64 produces a 64-bit
> guest with a 32-bit tool stack, so the crucial part of all the
> tests failing is not the guest's bitness, but tool stack's. So I'll
> next l
On Thu, Jan 15, 2015 at 02:31:01PM +, Xu, Quan wrote:
> Wei
>
> Are this series of patch in one thread? Thanks.
>
Yes.
> -Quan
>
> > -Original Message-
> > From: Xu, Quan
> > Sent: Thursday, January 15, 2015 5:22 PM
> > To: xen-devel@lists.xen.org; dgde...@tycho.nsa.gov
> > Cc: i
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, January 15, 2015 10:54 PM
> To: Xu, Quan
> Cc: wei.l...@citrix.com; xen-devel@lists.xen.org
> Subject: Re: FW: [PATCH v4 00/14] Enable vTPM subsystem on TPM 2.0
>
> On Thu, Jan 15, 2015 at 02:31:01PM +000
On 15/01/15 14:53, Jan Beulich wrote:
On 15.01.15 at 15:14, wrote:
>> But I think I made a wrong assumption above regarding the
>> guest size: test-amd64-i386-xl-win7-amd64 produces a 64-bit
>> guest with a 32-bit tool stack, so the crucial part of all the
>> tests failing is not the guest's
>>> On 15.01.15 at 16:06, wrote:
> On 15/01/15 14:53, Jan Beulich wrote:
> On 15.01.15 at 15:14, wrote:
>>> But I think I made a wrong assumption above regarding the
>>> guest size: test-amd64-i386-xl-win7-amd64 produces a 64-bit
>>> guest with a 32-bit tool stack, so the crucial part of all
On Tue, 2015-01-13 at 18:17 +, Julien Grall wrote:
> The define INVALID_GFN is misplaced in arch-arm/grant_table.h and is
> never used in neither in ARM nor in the common code.
Yeah, it appears to be an x86-ism which we copied over at some point.
> Therefore we can safely remove it.
>
> Sign
On Tue, 2015-01-13 at 18:17 +, Julien Grall wrote:
> When a domain is created on ARM, the grant table code initialized one
> grant frame. With a basic load (i.e disk usage), Xen is quickly trying
> to expand the number of frames:
>
> (XEN) grant_table.c:1305:d2v0 Expanding dom (2) grant table
We should honour -initrd and -append iff -kernel is specified, because
that's how QEMU works.
Check direct boot parameters in libxl__domain_build_info_setdefault.
Return failure if kernel is missing while ramdisk (-initrd) and / or
cmdline (-append) is present.
Signed-off-by: Wei Liu
Cc: Ian Cam
On Wed, 2015-01-14 at 18:00 +, Julien Grall wrote:
> Some platform (such as the VFP Base AEMv8 model) has a memory mapped
> timer. We don't want DOM0 use this timer rather than the generic ARM
> timer. So blacklist it for all platforms.
>
> Signed-off-by: Julien Grall
Acked + applied.
>
>
On Wed, 2015-01-14 at 15:47 +, Ian Campbell wrote:
> Otherwise continue without it, which is preferable to the current
> infinite hang.
>
> Slightly tweak the grammar of a comment in the same function.
>
> Signed-off-by: Ian Campbell
> Reviewed-by: Julien Grall
Now applied, thanks.
___
On Wed, 2015-01-14 at 17:55 +, Julien Grall wrote:
> Hi Ian,
>
> On 14/01/15 16:16, Ian Campbell wrote:
> > As well as the existing common perf counters add a bunch of ARM
> > specifics, including the various trap types, vuart/vgic/vtimer
> > accesses and different types of interrupt.
> >
> >
1 - 100 of 177 matches
Mail list logo
