Best Regards,
Robert Ho
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, February 12, 2015 1:04 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re:
On 13/02/2015 15:12, Ard Biesheuvel wrote:
On 13 February 2015 at 15:03, Julien Grall wrote:
Hi Ard,
On 12/02/2015 19:29, Ard Biesheuvel wrote:
This patch registers hvc0 as the preferred console if no console
has been specified explicitly on the kernel command line.
The purpose is to all
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, February 12, 2015 1:07 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 10/12] Compo
On 13 February 2015 at 15:03, Julien Grall wrote:
> Hi Ard,
>
>
> On 12/02/2015 19:29, Ard Biesheuvel wrote:
>>
>> 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 a
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 2:32 AM
> To: Wei Liu
> Cc: Hu, Robert; xen-devel@lists.xen.org; jfeh...@suse.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 01/12] Add support of par
Hi Ard,
On 12/02/2015 19:29, Ard Biesheuvel wrote:
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 w
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 2:21 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; jfeh...@suse.com;
> wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [P
Hi George,
在 11/03/2014 05:58 PM, George Dunlap 写道:
On 10/29/2014 05:49 AM, Wen Congyang wrote:
On 10/20/2014 10:25 PM, George Dunlap wrote:
On Wed, Oct 15, 2014 at 2:05 AM, Wen Congyang wrote:
On 10/14/2014 11:48 PM, Ian Jackson wrote:
Wen Congyang writes ("[PATCH 00/17] blktap2 related bu
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 2:17 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 11/12] Changes
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 & TICKET_
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, February 12, 2015 6:13 PM
> To: Hu, Robert
> Cc: Ian Jackson; xen-devel@lists.xen.org; jfeh...@suse.com;
> wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 01/12] Ad
flight 34484 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34341
Regressions which ar
## ### # # #
# # # ### # #
# # # # # # #
### # # # #
# # # # # # #
# # ### # #
#### # # #
David still wants a comment from the x86 maintainers...
Juergen
On 01/21/2015 0
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 fe
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"
> >
> > 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 agree
> From: Tim Deegan [mailto:t...@xen.org]
> Sent: Thursday, February 12, 2015 8:42 PM
>
> 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,
> > s
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 dirty
On 02/12/2015 10:10 PM, Andrew Cooper wrote:
On 12/02/15 06:54, Tian, Kevin wrote:
which presumably
means that the PML buffer flush needs to be aware of which gfns are
mapped by superpages to be able to correctly set a block of bits in the
logdirty bitmap.
Unfortunately PML itself can't tell
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, February 13, 2015 1:40 AM
> To: Xu, Quan; Olaf Hering
> Cc: Daniel De Graaf; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
>
> On 12/02/15 17:24, Xu, Q
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, Febru
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 bu
On 13 February 2015 at 05:18, Jordan Justen 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
I also have a version
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
test-amd64
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 sp
On Thu, 12 Feb 2015 20:08:46 +
Andrew Cooper 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 a
> justification for
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 prot
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"
> >
> > This unwraps XEN_BACKEND from depending on XEN_DOM0, it
> > instead makes it depend on the possible x86 backends and
> > under what scenerios its allow
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 thre
On Thu, 12 Feb 2015 20:08:33 +
Andrew Cooper 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 a
> justification for
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"
> >
> > Fold Xen front end drivers under their own Kconfig entry.
> > You may want to for example only enable domU guests with
> > pv-drivers.
> >
> > While a
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"
> >
> > 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 agr
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"
> >
> > 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 cha
On 12/02/15 19:44, Wei Liu wrote:
> Signed-off-by: Wei Liu
> Cc: Ian Campbell
> Cc: Ian Jackson
> ---
> 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 100644
> --- a/too
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 hid
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 hid
1. Extend grammar of parser.
2. Adjust internal functions to accept XLU_ConfigValue instead of
char *.
Signed-off-by: Wei Liu
Cc: Ian Jackson
Cc: Ian Campbell
Acked-by: Ian Jackson
---
tools/libxl/libxlu_cfg.c | 30 +++---
tools/libxl/libxlu_cfg_i.h | 5 +++--
to
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
Cc: Ian Campbell
Cc: Ian Jackson
---
Changes in v5:
1. New syntax for vNUMA configuration.
---
docs/man/xl.cfg.pod.5| 54 +
Hvmloader issues XENMEM_get_vnumainfo hypercall and stores the
information retrieved in scratch space for later use.
Signed-off-by: Wei Liu
Cc: Jan Beulich
---
Changes in v5:
1. Group scratch_alloc togeter.
2. Use memset.
3. Drop unnecessary "return";
4. Rebase onto Jan's errno ABI change.
Chan
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
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
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -67,6 +67,12 @@
* the same $
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
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 secondary table build.
---
tools/firmware/
This patches does following things:
1. Properly define a XLU_ConfigList type. Originally it was defined to
be XLU_ConfigSetting.
2. Define XLU_ConfigValue type, which can be either a string or a list
of XLU_ConfigValue.
3. ConfigSetting now references XLU_ConfigValue. Originally it only
w
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 sub-optimal
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
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.
---
tools/firmware/hvmloader/acpi/acpi2_0.h
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 (i.e
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
Cc: Ian Jac
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
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
Acked-by: Ian Campbell
--
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 constru
Signed-off-by: Wei Liu
Cc: Ian Campbell
Cc: Ian Jackson
---
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 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
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
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
Acked-by: Ian Campbell
---
tools/libxc/xc_hvm_b
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
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 pat
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
Hi all
This is version 5 of this series rebased on top of master.
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-wa
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 introduc
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 call
>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
Signed-off-by: Elena Ufimsteva
Signed-off-by: Wei Liu
Cc: Jan Beulich
---
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. Improve output.
Changes in v3:
1. Constify struct vnuma_i
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 alwa
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
Cc: Ian Campbell
Cc:
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 build
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
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Elena Ufimtseva
Acked-by: Ian Campbell
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 act
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 cal
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
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 (
https://hal.inria.fr/inria-00431031/PDF/Technical_Report_
Robert Ho writes ("[PATCH OSSTEST 12/12] Changes to test step of xen install"):
> This patch accomodates ts-xen-install to nested L1 xen installation
> usage. Its change is relatively simpler than
> ts-debain-hvm-install. We simply alter '$ho' usage to 'w_ho', which
> is assigned to '$ho' in or
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. B
flight 34471 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels
fail REGR. vs. 34227
t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-0268 / XSA-117
version 2
arm: vgic-v2: GICD_SGIR is not properly emulated
UPDATES IN VERSION 2
CVE assigned.
Mention CVE and XSA numbers in pat
On 12/02/15 17:24, Xu, Quan wrote:
>
>
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org
>> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan
>> Sent: Friday, February 13, 2015 12:57 AM
>> To: Olaf Hering
>> Cc: xen-devel@lists.xen.org
>> Sub
This allows the removal of 3 improper uses of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/hvm/hvm.c |2 +-
xen/arch/x86/mm.c |4 ++--
xen/arch/x86/mm/shadow/common.c | 18 --
xen
This involves introducing the domain variant of hash_foreach()
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 52 +--
xen/arch/x86/mm/shadow/multi.c |9 +++
xen/arch/x86/mm/shadow/multi.h |6
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |6 +++---
xen/arch/x86/mm/shadow/multi.c | 16
xen/arch/x86/mm/shadow/private.h | 11 ---
3 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/xen/arc
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 19 +--
xen/arch/x86/mm/shadow/multi.c | 30 +-
xen/arch/x86/mm/shadow/multi.h |8
xen/arch/x86/mm/shadow/private.h |9
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 11 +--
xen/arch/x86/mm/shadow/multi.c |4 +---
xen/arch/x86/mm/shadow/multi.h |2 +-
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/comm
This allows the removal an improper use of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |7 +++
xen/arch/x86/mm/shadow/multi.c | 16 ++--
xen/arch/x86/mm/shadow/private.h |2 +-
3
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 19 ++-
xen/arch/x86/mm/shadow/multi.c |6 ++
xen/arch/x86/mm/shadow/multi.h |4 ++--
xen/arch/x86/mm/shadow/private.h |2 +-
4 files changed, 15 insertions(+
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 12 ++--
xen/arch/x86/mm/shadow/multi.c | 13 +
xen/arch/x86/mm/shadow/multi.h |6 +++---
xen/arch/x86/mm/shadow/private.h |2 +-
4 files changed, 15 insertions
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/multi.c | 69
1 file changed, 35 insertions(+), 34 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index ccb08d3..1db8161
There existed some codepaths which had a domain in their hand, but needed a
vcpu to drive the shadow interface.
Now that these interfaces have changed to be domain based, the hoop-jumping
can be removed.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/co
This allows the removal an improper use of d->vcpu[0] from toolstack context
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 13 ++---
xen/arch/x86/mm/shadow/multi.c |3 +--
xen/arch/x86/mm/shadow/multi.h |2 +-
3 files chan
> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan
> Sent: Friday, February 13, 2015 12:57 AM
> To: Olaf Hering
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] stubdom vtpm build fa
The purpose of this series is to prevent toolstack entry points into the
shadow code from passing d->vcpu[0] for actions which are inherenly domain
wide. It also fixes the fact that shadow heuristics were being applied to
vcpu 0 for toolstack-initiated actions.
This series is composed mostly of m
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 23 ---
xen/arch/x86/mm/shadow/multi.c | 19 ---
xen/arch/x86/mm/shadow/private.h |6 +++---
3 files changed, 27 insertions(+), 21 deletions(-)
diff
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 11 ---
xen/arch/x86/mm/shadow/multi.c | 22 +-
xen/arch/x86/mm/shadow/private.h |6 +++---
3 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/x
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/multi.c | 99 +++-
1 file changed, 48 insertions(+), 51 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 1e6bc33..154274f
All of the introduced domain pointers will eventually be removed, but doing
this mechanical cleanup here allows the subsequent patches which change
function prototypes to be smaller and more clear.
In addition, swap some use of is_pv_32on64_vcpu(v) for is_pv_32on64_domain(d).
No functional change
It is incorrect to be applying these heuristics because of toolstack actions.
As the vcpu parameters are to be replaced with domain parameters, guest
context is identified by using current->domain.
Note that the majority of the heuristics in sh_remove_write_access() were
already restricted to gue
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |7 ---
xen/arch/x86/mm/shadow/multi.c | 10 +-
xen/arch/x86/mm/shadow/private.h | 18 ++
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/xen/a
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c |6 ++
xen/arch/x86/mm/shadow/multi.c | 10 +-
xen/arch/x86/mm/shadow/private.h |4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/mm/shado
A later change requires the introduction of a domain variant.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
---
xen/arch/x86/mm/shadow/common.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c
Sorry for that. Read the other thread of email, it looks that some maintainers
are working for this issue.
And I am working for 'Xen stubdom vTPM for HVM virtual machine' v4 patches.
There are a lot of modifications.
I will be out of office from Feb. 16th to Feb. 26th for Chinese New Year. I
p
On 02/11, Jeremy Fitzhardinge wrote:
>
> On 02/11/2015 09:24 AM, Oleg Nesterov wrote:
> > I agree, and I have to admit I am not sure I fully understand why
> > unlock uses the locked add. Except we need a barrier to avoid the race
> > with the enter_slowpath() users, of course. Perhaps this is the
On 12/02/15 16:33, Boris Ostrovsky wrote:
> On 02/12/2015 10:48 AM, Andrew Cooper wrote:
>> On 12/02/15 15:38, Boris Ostrovsky wrote:
>>> On 02/12/2015 10:21 AM, Andrew Cooper wrote:
On 12/02/15 15:01, Boris Ostrovsky wrote:
> On 02/12/2015 06:04 AM, Andrew Cooper wrote:
>> On 11/02/15
On Monday, February 9, 2015 07:02, Juergen Gross wrote:
> To: Kristian Hagsted Rasmussen; Olaf Hering; xen-de...@lists.xensource.com
> Subject: Re: [Xen-devel] pvSCSI test
snip
>
> No, that's okay. The connection between p-dev and the drive is done
> via the target infrastructure.
>
> Somethin
On 02/12/2015 11:33 AM, Boris Ostrovsky wrote:
Also, for %*ph format, if we just go with falling through to plain
format and not marking somehow that we are printing a bad pointer:
unsigned badval = 0xab;
unsigned *badptr = &badval;
printk("badptr = %*ph\n", 1, badptr);
console:
flight 34468 linux-3.14 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check fail REGR. vs. 34268
Regressions which are
On 02/12/2015 10:48 AM, Andrew Cooper wrote:
On 12/02/15 15:38, Boris Ostrovsky wrote:
On 02/12/2015 10:21 AM, Andrew Cooper wrote:
On 12/02/15 15:01, Boris Ostrovsky wrote:
On 02/12/2015 06:04 AM, Andrew Cooper wrote:
On 11/02/15 20:58, Boris Ostrovsky wrote:
If invalid pointer (i.e. someth
On 12/02/15 15:38, Boris Ostrovsky wrote:
> On 02/12/2015 10:21 AM, Andrew Cooper wrote:
>> On 12/02/15 15:01, Boris Ostrovsky wrote:
>>> On 02/12/2015 06:04 AM, Andrew Cooper wrote:
On 11/02/15 20:58, Boris Ostrovsky wrote:
> If invalid pointer (i.e. something smaller than
> HYPERVISO
flight 34461 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 34299
test-amd64-i386-qemut-
1 - 100 of 174 matches
Mail list logo
