>>> On 24.06.15 at 03:11, wrote:
> On 2015/6/23 18:12, Jan Beulich wrote:
> On 23.06.15 at 11:57, wrote:
>>> --- a/xen/drivers/passthrough/vtd/iommu.c
>>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>> @@ -1839,7 +1839,7 @@ static int rmrr_identity_mapping(struct domain *d,
>>> bool_t map,
>>
> -Original Message-
> From: Meng Xu [mailto:xumengpa...@gmail.com]
> Sent: Wednesday, June 24, 2015 2:16 PM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich; Zhang, Yang Z
> Subject: Re: [Xen-devel] [v3 01/15] Vt-d Posted
Hi Feng,
One minor thing:
> +Important Definitions
> +==
> +There are some changes to IRTE and posted-interrupt descriptor after
> +VT-d PI is introduced:
> +IRTE:
It seems that you forgot to define IRTE. :-)
I guess it stands for Interrupt Remapping Table Entry? (Probably I'm wr
flight 58849 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 58830
Tests which did not
On 06/24/2015 12:27 AM, Lengyel, Tamas wrote:
> I've extended xen-access to exercise this new feature taking into
> account some of the current limitations. Using the altp2m_write|exec
> options we create a duplicate view of the default hostp2m, and instead
> of relaxing the mem_access permissions
This patch includes the following aspects:
- Add a global vector to wake up the blocked vCPU
when an interrupt is being posted to it (This
part was sugguested by Yang Zhang ).
- Adds a new per-vCPU tasklet to wakeup the blocked
vCPU. It can be used in the case vcpu_unblock
cannot be called
Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot send
posted-interrupt when 'SN' is set.
Signed-off-by: Feng Wu
---
v3:
use cmpxchg to test SN/ON and set ON
xen/arch/x86/hvm/vmx/vmx.c | 32
1 file
Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
Signed-off-by: Feng Wu
---
v3:
- Use u32 instead of u64 for the bitfield in 'struct pi_desc'
xen/include/asm-x86/hvm/vmx/vmcs.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/xen/include/asm-x8
When a vCPU is running in Root mode and a notification event
has been injected to it. we need to set VCPU_KICK_SOFTIRQ for
the current cpu, so the pending interrupt in PIRR will be
synced to vIRR before VM-Exit in time.
Signed-off-by: Feng Wu
---
v3:
- Make pi_notification_interrupt() static
xe
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
This patch adds feature detection logic for VT-d
Add macro cpu_has_cx16 to detect X86_FEATURE_CX16 feature.
Signed-off-by: Feng Wu
---
v3:
- Newly added. We need to atomically update the IRTE in PI format
via CMPXCHG16B which is only available with this feature.
xen/include/asm-x86/cpufeature.h | 2 ++
1 file changed, 2 insertions(+)
diff
When guest changes its interrupt configuration (such as, vector, etc.)
for direct-assigned devices, we need to update the associated IRTE
with the new guest vector, so external interrupts from the assigned
devices can be injected to guests without VM-Exit.
For lowest-priority interrupts, we use ve
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
This patch adds variable 'iommu_intpost' to contr
The basic idea here is:
1. When vCPU's state is RUNSTATE_running,
- set 'NV' to 'Notification Vector'.
- Clear 'SN' to accpet PI.
- set 'NDST' to the right pCPU.
2. When vCPU's state is RUNSTATE_blocked,
- set 'NV' to 'Wake-up Vector', so we can wake up the
Enable VT-d Posted-Interrupts and add a command line
parameter for it.
Signed-off-by: Feng Wu
---
v3:
Remove the redundant "no intremp then no intpost" logic
docs/misc/xen-command-line.markdown | 9 -
xen/drivers/passthrough/iommu.c | 4 +++-
2 files changed, 11 insertions(+), 2 del
This patch adds cmpxchg16b support for x86-64, so software
can perform 128-bit atomic write/read.
Signed-off-by: Feng Wu
---
v3:
Newly added.
xen/include/asm-x86/x86_64/system.h | 28
xen/include/xen/types.h | 5 +
2 files changed, 33 insertions(+)
Extend struct iremap_entry according to VT-d Posted-Interrupts Spec.
Signed-off-by: Feng Wu
---
v3:
- Use u32 instead of u64 to define the bitfields in 'struct iremap_entry'
- Limit using bitfield if possible
xen/drivers/passthrough/vtd/intremap.c | 92 +-
xen/dr
This patch adds an API which is used to update the IRTE
for posted-interrupt when guest changes MSI/MSI-X information.
Signed-off-by: Feng Wu
---
v3:
- Remove "adding PDA_MASK()" when updating 'pda_l' and 'pda_h' for IRTE.
- Change the return type of pi_update_irte() to int.
- Remove some pointle
Add the design doc for VT-d PI.
Signed-off-by: Feng Wu
---
docs/misc/vtd-pi.txt | 333 +++
1 file changed, 333 insertions(+)
create mode 100644 docs/misc/vtd-pi.txt
diff --git a/docs/misc/vtd-pi.txt b/docs/misc/vtd-pi.txt
new file mode 100644
ind
VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.
You can find the VT-d Posted-Interrtups Spec. in
This patch initializes the VT-d Posted-interrupt Descriptor.
Signed-off-by: Feng Wu
---
v3:
- Move pi_desc_init() to xen/arch/x86/hvm/vmx/vmcs.c
- Remove the 'inline' flag of pi_desc_init()
xen/arch/x86/hvm/vmx/vmcs.c | 18 ++
xen/include/asm-x86/hvm/vmx/vmx.h | 2 ++
2 f
Document Day is here! Join us in #xendocs on Freenode IRC and help us
make us our Wiki even better!
On Tue, Jun 23, 2015 at 12:01 AM, Russ Pavlicek
wrote:
> Our next Document Day is this Wednesday. This month, we'd like to
> catch up with the latest advances in the project. Some topics to
> ad
On 06/23/2015 09:38 AM, Jan Beulich wrote:
On 20.06.15 at 05:09, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2652,7 +2652,7 @@ int vcpu_destroy_pagetables(struct vcpu *v)
if ( rc )
return rc;
-if ( is_pv_32on64_vcpu(v) )
+if ( is_pv_32on64_vcpu(v) && !
On 06/23/2015 09:25 AM, Jan Beulich wrote:
On 20.06.15 at 05:09, wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -584,7 +584,7 @@ int arch_domain_create(struct domain *d, unsigned int
domcr_flags,
mapcache_domain_init(d);
HYPERVISOR_COMPAT_VIRT_START(d) =
-
On 06/23/2015 09:22 AM, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,12 +2320,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
v->arch.hvm_vcpu.inject_trap.vector = -1;
if ( is_pvh_domain(d) )
-{
-v->arch.hvm_vcpu.hcall_64bit = 1;
On 06/23/2015 09:12 AM, Stefano Stabellini wrote:
On Tue, 23 Jun 2015, Ian Campbell wrote:
On Tue, 2015-06-23 at 11:55 +0100, Stefano Stabellini wrote:
I don't know if we should introduce a new name for this, but I wanted to
point out that this is different from PVH from Xen point of view. In
p
On 06/23/2015 08:30 AM, Jan Beulich wrote:
On 22.06.15 at 18:37, wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1444,6 +1444,9 @@ const struct hvm_function_table * __init
start_svm(void)
svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
>>> On 6/23/2015 at 07:29 PM, in message <558942ff.5060...@eu.citrix.com>,
>>> George
Dunlap wrote:
> On 06/23/2015 11:18 AM, Chun Yan Liu wrote:
> On 6/16/2015 at 01:47 AM, in message <557f0fa7.2060...@eu.citrix.com>,
> George
> > Dunlap wrote:
> >>> +static int libxl__device_us
On 06/23/2015 04:26 AM, Jan Beulich wrote:
On 22.06.15 at 18:10, wrote:
On 06/22/2015 11:10 AM, Jan Beulich wrote:
+switch ( op )
+{
+case XENPMU_mode_set:
+{
+if ( (pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
+ (hweight64(pmu_params.val) > 1)
flight 58839 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58839/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 13 guest-saverestore fail REGR. vs. 58106
Regressions which are
flight 58842 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58842/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 11 guest-start fail like 58823
test-amd64-amd64-libvirt 11 gu
On 2015/6/23 18:12, Jan Beulich wrote:
On 23.06.15 at 11:57, wrote:
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1839,7 +1839,7 @@ static int rmrr_identity_mapping(struct domain *d, bool_t
map,
while ( base_pfn < end_pfn )
flight 58837 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58837/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 11 guest-start fail REGR. vs. 58776
Regressions which
Hey Jens,
Please git pull the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-4.2
in your 'for-4.2/drivers' branch. It is late - for which I am terrible
sorry! The patches have been sitting in my branch for two weeks - except
the last patch which w
flight 58835 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 14 guest-start.2fail REGR. vs. 58451
test-amd64-amd64-
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> PCI BARs tell us whether prefetching is safe, but they don't say anything
> about write combining (WC). WC changes ordering rules and allows writes to
> be collapsed, so it's not safe in general to use it
On 06/23/2015 02:27 PM, Lengyel, Tamas wrote:
>> Testability is still a potential issue. We have offered to make our
>> internal
>> Windows test binaries available for intra-domain testing. Tamas has
>> been working on toolstack support for cross-domain testing with a slightly
>> earlier patch seri
On Tue, Jun 23, 2015 at 06:46:08PM +0200, Jan Kara wrote:
> Looks good to me. BTW also ext4 (with BIGALLOC feature) and OCFS2 can have
> block allocation unit (called cluster) larger than page size. However the
> block size of both filesystems is still <= page size. So at least ext4
> handles fun
> Testability is still a potential issue. We have offered to make our
> internal
> Windows test binaries available for intra-domain testing. Tamas has
> been working on toolstack support for cross-domain testing with a slightly
> earlier patch series, and we hope he will submit that support.
>
Hi
flight 58838 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58838/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 20 guest-start/debianfail REGR. vs. 58046
Regressions which are
On 06/23/2015 07:12 AM, Ian Jackson wrote:
Ian Jackson writes ("Re: [Xen-devel] Tools backports for 4.5 [and 1 more
messages]"):
Jan Beulich writes ("Re: [Xen-devel] Tools backports for 4.5"):
3380f5b6270e ocaml/xenctrl: Check return values from hypercalls
c8945d516134 ocaml/xenctrl: Make fail
On Tue, Jun 23, 2015 at 2:52 PM, Ed White wrote:
> On 06/23/2015 11:15 AM, Lengyel, Tamas wrote:
> > On Mon, Jun 22, 2015 at 2:56 PM, Ed White
> wrote:
> >
> >> Add the remaining routines required to support enabling the alternate
> >> p2m functionality.
> >>
> >> Signed-off-by: Ed White
> >> -
On 06/18/2015 09:18 AM, Ian Campbell wrote:
On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote:
The "No response from client ..." appear only on armhf as far as I can
tell.
Indeed, and I just noticed while developing osstest for arm64 that the
daemon is segfaulting, and we even managed to
On Fri, May 29, 2015 at 2:37 AM, Tamas K Lengyel
wrote:
> The sharing vm_event ring being enabled is not necessary for mem_sharing
> memops.
>
> Signed-off-by: Tamas K Lengyel
> ---
> xen/arch/x86/mm/mem_sharing.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/xen/arch/x86/mm/mem_s
I think it's amazing that you're doing this work and I'll be happy to help
if you keep me on cc.
It's not serious for me to claim I'm a maintainer when I don't have the
time nor the resources to do serious debugging should the need arise.
Andres
On Tue, Jun 23, 2015 at 10:33 AM, Lengyel, Tamas
On 06/23/2015 11:15 AM, Lengyel, Tamas wrote:
> On Mon, Jun 22, 2015 at 2:56 PM, Ed White wrote:
>
>> Add the remaining routines required to support enabling the alternate
>> p2m functionality.
>>
>> Signed-off-by: Ed White
>> ---
>> xen/arch/x86/hvm/hvm.c | 60 +-
>> xen/arch
On Tue, Jun 23, 2015 at 05:38:17PM +0100, Ian Campbell wrote:
> On Tue, 2015-06-23 at 17:32 +0100, Wei Liu wrote:
> > On Tue, Jun 23, 2015 at 03:58:32PM +0100, Ian Campbell wrote:
> > > There is an issue in libxl_set_memory_target whereby the target and
> > > the max mem can get out of sync, this i
On 06/18/2015 10:02 AM, Ian Campbell wrote:
On Thu, 2015-06-18 at 16:18 +0100, Ian Campbell wrote:
On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote:
The "No response from client ..." appear only on armhf as far as I can
tell.
Indeed, and I just noticed while developing osstest for arm64
On Mon, Jun 22, 2015 at 2:56 PM, Ed White wrote:
> Add the remaining routines required to support enabling the alternate
> p2m functionality.
>
> Signed-off-by: Ed White
> ---
> xen/arch/x86/hvm/hvm.c | 60 +-
> xen/arch/x86/mm/hap/Makefile| 1 +
> xen/arch/x86/mm/ha
That's indeed sad. I'm actively using the sharing system in my tools and
have a couple branches laying around for improving it, like batch
memsharing for example to support flash-cloning. Now that it's orphaned,
how would I go about merging these into mainline? I'm not yet confident
enough in my un
On 23 June 2015 at 17:19, Stefano Stabellini
wrote:
> On Tue, 23 Jun 2015, Peter Maydell wrote:
>> I have a bit in my pull-request-creation script that automatically
>> checks that every commit has my signoff, to avoid this kind of
>> mistake:
>> https://git.linaro.org/people/peter.maydell/misc-sc
On Tue, Jun 23, 2015 at 6:22 AM, Tim Deegan wrote:
> This code now has no active maintainers, as neither Andres nor I
> can commit the time.
>
> Signed-off-by: Tim Deegan
> Cc: Andres Lagar-Cavilla
>
Wistfully, Acked-by: Andres Lagar-Cavilla
> ---
> MAINTAINERS | 4 +---
> 1 file changed, 1
Hi,
Ping? I don't think this patch series depends on others (such as Linux
64K support) to review it.
Regards,
On 11/05/15 12:55, Julien Grall wrote:
> Hi all,
>
> This small series are the only changes required in Xen in order to run a guest
> using 64K page granularity on top of an unmodified
On Sat 20-06-15 00:07:39, Al Viro wrote:
> On Wed, Jun 17, 2015 at 09:31:16PM +0100, Al Viro wrote:
> > On Wed, Jun 17, 2015 at 10:57:15AM +0200, Jan Kara wrote:
> > > > Joy... Folks, is anybody actively maintaining fs/ufs these days?
> > >
> > > Looking into the changelog there wasn't anyone ser
Hi Vijay,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> This patch introduces virtual ITS driver with following
> functionality
> - Introduces helper functions to manage device table and
>ITT table in guest memory
> - Helper function to handle virtual ITS devi
On Tue, 2015-06-23 at 17:32 +0100, Wei Liu wrote:
> On Tue, Jun 23, 2015 at 03:58:32PM +0100, Ian Campbell wrote:
> > There is an issue in libxl_set_memory_target whereby the target and
> > the max mem can get out of sync, this is because the call the
> > xc_domain_setmaxmem is not tied in any way
On Tue, Jun 23, 2015 at 03:58:32PM +0100, Ian Campbell wrote:
> There is an issue in libxl_set_memory_target whereby the target and
> the max mem can get out of sync, this is because the call the
> xc_domain_setmaxmem is not tied in any way to the xenstore transaction
> which controls updates to th
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 June 2015 17:22
> To: Paul Durrant
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: RE: [PATCH v3 04/18] x86/hvm: make sure translated MMIO reads or
> writes fall within a page
>
>
On 06/23/2015 04:19 PM, Jan Beulich wrote:
> ... as being identical to is_pv_32bit_domain() after the x86-32
> removal.
>
> In a few cases this includes no longer open-coding is_pv_32bit_vcpu().
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
>
> --- a/xen/arch/x86/domain.c
> +++ b
"Jan Beulich" writes:
On 26.05.15 at 15:32, wrote:
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1709,9 +1709,9 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
>> const struct npfec npfec)
>>
>> /*
>> * Set access type for a region of pfns.
>> - * If start_pf
>>> On 23.06.15 at 18:13, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 23 June 2015 16:53
>> To: Paul Durrant
>> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
>> Subject: Re: [PATCH v3 04/18] x86/hvm: make sure translated MMIO r
On Tue, 23 Jun 2015, Peter Maydell wrote:
> On 23 June 2015 at 11:30, Stefano Stabellini
> wrote:
> > On Tue, 23 Jun 2015, Peter Maydell wrote:
> >> I'm afraid I can't apply this -- this revert commit is missing a
> >> signed-off-by
> >> line. Can you respin, please?
> >
> > I thought that being
>>> On 22.05.15 at 17:50, wrote:
> Summary is that VMware treats "in (%dx),%eax" (or "out %eax,(%dx)")
> to port 0x5658 specially. Note: since many operations return data
> in EAX, "in (%dx),%eax" is the one to use. The other lengths like
> "in (%dx),%al" will still do things, only AL part of EA
On 06/23/2015 04:20 PM, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1851,9 +1851,7 @@ unsigned long paging_gva_to_gfn(struct v
> struct p2m_domain *hostp2m = p2m_get_hostp2m(v->domain);
>
On Tue, 23 Jun 2015, Julien Grall wrote:
> On 23/06/15 15:49, Stefano Stabellini wrote:
> > Yes, you are right, I was reading an older version of Linux that still
> > had xen_remap_domain_mfn_range properly implemented.
> >
> > The new function is called xen_remap_domain_mfn_array which calls
> >
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 23 June 2015 16:53
> To: Paul Durrant
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH v3 04/18] x86/hvm: make sure translated MMIO reads or
> writes fall within a page
>
>
As a preparation before adding new restart type (soft reset) put all
restart types into an enum.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Ian Campbell
---
Changes since v7:
- s,restarter,restarted, [Ian Campbell]
---
tools/libxl/xl.h | 6 ++
tools/libxl/xl_cmdimpl.c | 23 +
Log first 10 active grants of a domain. This function is going to be used
for soft reset, active grants on this path usually mean misbehaving backends
refusing to release their mappings on shutdown.
Signed-off-by: Vitaly Kuznetsov
---
xen/common/grant_table.c | 31 ++
We need to close all event channel so the domain performing soft reset
will be able to open them back.
Signed-off-by: Vitaly Kuznetsov
---
xen/common/event_channel.c | 38 +++---
xen/include/xen/event.h| 3 +++
2 files changed, 22 insertions(+), 19 deletions(
Introduce xc_domain_soft_reset() function supporting XEN_DOMCTL_soft_reset.
Signed-off-by: Vitaly Kuznetsov
---
tools/libxc/include/xenctrl.h | 3 +++
tools/libxc/xc_domain.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/
Use existing create/restore path to perform 'soft reset' for HVM domains.
Tear everything down, e.g. destroy domain's device model, remove the domain
from xenstore, save toolstack record and start over.
Signed-off-by: Vitaly Kuznetsov
---
Changes since 'v7'
- 'Reset everything approach': XEN_DOMC
Use this in libxl_dm instead of hard-coding.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Ian Campbell
---
tools/libxc/include/xenguest.h | 2 ++
tools/libxl/libxl_dm.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/includ
Add new soft_reset vector to domain2 class, add it to create_domain
in the default policy.
Signed-off-by: Vitaly Kuznetsov
---
tools/flask/policy/policy/modules/xen/xen.if | 2 +-
xen/xsm/flask/hooks.c| 3 +++
xen/xsm/flask/policy/access_vectors | 2 ++
3 files c
New domctl resets state for a domain allowing it to 'start over': register
vcpu_info, switch to FIFO ABI for event channels. Still active grants are
being logged to help debugging misbehaving backends.
Signed-off-by: Vitaly Kuznetsov
---
xen/common/domain.c | 29 +
This patch series provides x86 PVHVM domains with an ability to perform
kexec/kdump-style operations.
The list of currently known issues blocking kexec (and why the series is
required) is:
- Bound event channels.
- Registered vcpu_info.
- PIRQ/emuirq mappings.
- shared_info frame after XENMAPSPACE
Use letter 'S' to indicate a domain in such state.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Ian Campbell
---
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 +-
tools/python/xen/lowlevel/xl/xl.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a
x86-specific hook cleans up the pirq-emuirq mappings, destroys all ioreq
servers and and replaces the shared_info frame with an empty page to support
subsequent XENMAPSPACE_shared_info call.
ARM-specific hook is a noop for now.
Signed-off-by: Vitaly Kuznetsov
---
Changes since 'PATCH RFC' of the
This special type of shutdown is supposed to be used by PVHVM guests when
they want to perform some sort of kexec/kdump.
Signed-off-by: Vitaly Kuznetsov
---
xen/common/shutdown.c | 6 ++
xen/include/public/sched.h | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/xe
This reverts commit 0c029c4da2169159064568ef4fea862a5d2cd84a.
A new memory model that allows QEMU to bump memory behind libxl's back
was merged a few months ago. We didn't fully understand the
repercussions back then. Now it breaks migration and becomes blocker of
4.6 release.
It's better to rest
That is, the date without the suite suffix.
Signed-off-by: Ian Campbell
---
mg-debian-installer-update | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index ba2fdc4..59f05ec 100755
--- a/mg-debian-installer-updat
Where "appropriate" means if TftpDiVersion is set to current, which is
the default in standalone mode. The assumption is that someone wuth
that configration runs mg-debian-installer-update then they would
expected the update to be immediately effective.
There was some existing, but commented, code
flight 58834 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58834/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58756
test-amd64-i386-xl-qemuu-win7-amd64 1
On Tue, 2015-06-23 at 16:50 +0100, Ian Jackson wrote:
> > And with that - will it ever clear?
>
> Not unless we get lucky and that guest-stop passes.
The guest-stop is (now) an allowable fail. After discussing this with
Ian f2f it seems that he underlying issue is that the allowable-ness
check is
>>> On 23.06.15 at 12:39, wrote:
> ...otherwise they will simply carry on to the next page using a normal
> linear-to-phys translation.
And what's wrong about this?
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -586,7 +586,6 @@ static int __hvmemul_read(
>
Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 58817: FAIL"):
> >>> On 22.06.15 at 08:54, wrote:
> > flight 58817 xen-4.2-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/58817/
> >
> > Failures and problems with tests :-(
> >
> > Tests which did not succeed
On 23/06/15 16:09, Jan Beulich wrote:
> - remove vcpu_info from xlat.lst (it isn't and can't be checked)
> - drop pointless (redundant) casts
> - make dummy_vcpu_info static
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel maili
On 23/06/15 16:20, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 23/06/15 16:19, Jan Beulich wrote:
> ... as being identical to is_pv_32bit_domain() after the x86-32
> removal.
>
> In a few cases this includes no longer open-coding is_pv_32bit_vcpu().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
On 23/06/15 16:18, Jan Beulich wrote:
> ... as being identical to is_pv_32bit_vcpu() after the x86-32 removal.
>
> In a few cases this includes an additional is_pv_32bit_vcpu() ->
> is_pv_32bit_domain() conversion.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1851,9 +1851,7 @@ unsigned long paging_gva_to_gfn(struct v
struct p2m_domain *hostp2m = p2m_get_hostp2m(v->domain);
const struct paging_mode *hostmode = paging_get_hostmode(v);
-if ( is_hvm_doma
... as being identical to is_pv_32bit_domain() after the x86-32
removal.
In a few cases this includes no longer open-coding is_pv_32bit_vcpu().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -367,7 +367,7 @@ int switch_native(struct domain *d)
if (
... as being identical to is_pv_32bit_vcpu() after the x86-32 removal.
In a few cases this includes an additional is_pv_32bit_vcpu() ->
is_pv_32bit_domain() conversion.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1339,7 +1339,7 @@ long
flight 58833 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58833/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 584
1: drop is_pv_32on64_vcpu()
2: drop is_pv_32on64_domain()
3: use is_..._vcpu() instead of open coding it
Some of this extends into common code, hence the wider Cc list.
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
> >> * Leaf 0x0007[ECX=0].EAX
> >> * `mask_l7s0_ebx`
> > Those 'l' look like '1' in the PDF.
> >
> > Can it be called something else?
>
> If you can suggest a better name, yes. As for now, these are the
> variable names used in-tree (top of xen/arch/x86/cpu/amd.c)
low?
>
> >
> >> *
- remove vcpu_info from xlat.lst (it isn't and can't be checked)
- drop pointless (redundant) casts
- make dummy_vcpu_info static
Signed-off-by: Jan Beulich
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -70,7 +70,7 @@ integer_param("hardware_dom", hardware_d
struct vcpu *idle_vcpu[NR
On 23/06/15 15:49, Stefano Stabellini wrote:
> Yes, you are right, I was reading an older version of Linux that still
> had xen_remap_domain_mfn_range properly implemented.
>
> The new function is called xen_remap_domain_mfn_array which calls
> xen_xlate_remap_gfn_array.
>
> I'll rephrase my ques
On Tue, 2015-06-23 at 15:52 +0100, Wei Liu wrote:
> On Tue, Jun 23, 2015 at 03:45:14PM +0100, Jan Beulich wrote:
> > >>> On 23.06.15 at 16:16, wrote:
> > > This reverts commit f5b43e95facdc17f925cb56a8963cd4531074034.
> >
> > Even if the patch having introduced the regression this fixed is
> > be
On 23 June 2015 at 11:30, Stefano Stabellini
wrote:
> On Tue, 23 Jun 2015, Peter Maydell wrote:
>> I'm afraid I can't apply this -- this revert commit is missing a
>> signed-off-by
>> line. Can you respin, please?
>
> I thought that being a straight revert, didn't need a SOB line.
> xen-220615-2
There is an issue in libxl_set_memory_target whereby the target and
the max mem can get out of sync, this is because the call the
xc_domain_setmaxmem is not tied in any way to the xenstore transaction
which controls updates to the xenstore side of things.
Consider a domain with 1M of RAM (==target
1 - 100 of 277 matches
Mail list logo
