>>> On 26.10.17 at 19:03, wrote:
> +static int operand_read(void *buf, struct vmx_inst_op *op,
> +struct cpu_user_regs *regs, unsigned int bytes)
const (twice)
> +{
> +if ( op->type == VMX_INST_MEMREG_TYPE_REG )
> +{
> +switch ( bytes )
> +{
> +
>>> On 26.10.17 at 19:03, wrote:
> * invvpid has a 128-bit memory operand but we only require the VPID value
> which lies in the lower 64 bits.
The memory operand (wrongly) isn't being read at all - I don't
understand the above bullet point for that reason.
> @@ -464,6 +462,8 @@ static int dec
>>> On 26.10.17 at 19:03, wrote:
> hvm_copy_{to,from}_guest_virt() copy data to and from a guest, performing
> segmentatino and paging checks on the provided seg:offset virtual address.
I'm not sure "paging" is worthwhile to mention here, as that's not
done by the new functions, but by the existi
>>> On 27.11.17 at 19:08, wrote:
> On 27/11/17 17:01, Jan Beulich wrote:
> On 26.10.17 at 19:03, wrote:
>>> +return X86EMUL_OKAY;
>> This and ...
>>
>>> +}
>>> +else
>>> +{
>>> +pagefault_info_t pfinfo;
>>> +int rc = hvm_copy_from_guest_linear(buf, op->mem,
>>> On 26.10.17 at 19:03, wrote:
In the title please use "read/write" or "access".
> @@ -380,17 +383,7 @@ static int operand_read(void *buf, struct vmx_inst_op
> *op,
> return X86EMUL_OKAY;
> }
> else
> -{
> -pagefault_info_t pfinfo;
> -int rc = hvm_copy_f
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-pair
testid xen-boot/src_host
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git
flight 116607 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116607/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116520
test-armhf-armhf-libvirt-raw 13 saveresto
Xen PVH guests receive the address of the RSDP table from Xen. In order
to support booting a Xen PVH guest via grub2 using the standard x86
boot entry we need a way fro grub2 to pass the RSDP address to the
kernel.
For this purpose expand the struct setup_header to hold the physical
address of the
In case the rsdp address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
drivers/acpi/osl.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/osl.c b/driv
In the non-EFI boot path the ACPI RSDP table is currently found via
either EBDA or by searching through low memory for the RSDP magic.
This requires the RSDP to be located in the first 1MB of physical
memory. Xen PVH guests, however, get the RSDP address via the start of
day information block.
In
When booted via the special PVH entry save the RSDP address set in the
boot information block in struct boot_params. This will enable Xen to
locate the RSDP at an arbitrary address.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pvh.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
>>> On 28.11.17 at 10:12, wrote:
> In theory the BIOS would search for address space and won't find
> anything, so the hotplug operation should fail even before it reaches
> the kernel in the first place.
How would the BIOS know what the OS does or plans to do? I think
it's the other way around
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2017 08:29
> To: xen-devel
> Cc: Julien Grall ; Andrew Cooper
> ; Paul Durrant
> Subject: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
>
> handle_hvm_io_completion() is bei
>>> On 28.11.17 at 10:49, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 November 2017 08:29
>> To: xen-devel
>> Cc: Julien Grall ; Andrew Cooper
>> ; Paul Durrant
>> Subject: [PATCH] x86/HVM: fix interaction between internal and extern
>> emula
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:02
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
>
> >
On Tue, Nov 28, 2017 at 10:43:58AM +0100, Juergen Gross wrote:
> Xen PVH guests receive the address of the RSDP table from Xen. In order
> to support booting a Xen PVH guest via grub2 using the standard x86
> boot entry we need a way fro grub2 to pass the RSDP address to the
> kernel.
>
> For this
>>> On 28.11.17 at 11:05, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 November 2017 10:02
>> >>> On 28.11.17 at 10:49, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 27 November 2017 08:29
>> >> handle_hvm_io_completion() is being involved in resuming
On Tue, Nov 28, 2017 at 10:44:00AM +0100, Juergen Gross wrote:
> When booted via the special PVH entry save the RSDP address set in the
> boot information block in struct boot_params. This will enable Xen to
> locate the RSDP at an arbitrary address.
>
> Signed-off-by: Juergen Gross
> ---
> arch
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel in the first place.
How would the BIOS know what the OS does or plans to do
On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote:
> In case the rsdp address in struct boot_params is specified don't try
> to find the table by searching, but take the address directly as set
> by the boot loader.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/acpi/osl.c | 8
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:17
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
>
> >
On 28/11/17 11:18, Roger Pau Monné wrote:
> On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote:
>> In case the rsdp address in struct boot_params is specified don't try
>> to find the table by searching, but take the address directly as set
>> by the boot loader.
>>
>> Signed-off-by: Jue
flight 116596 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116596/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm broken
test-amd64-i386-libv
>>> On 28.11.17 at 11:22, wrote:
> It would definitely be good to only reset io_completion when it is clear
> that handle_hvm_io_completion() is not going to be called (i.e. for
> internally handled I/O)
Where would you suggest to do that? These two ...
> and perhaps even add ASSERTs in _hvm_e
On 28/11/17 11:17, Roger Pau Monné wrote:
> On Tue, Nov 28, 2017 at 10:44:00AM +0100, Juergen Gross wrote:
>> When booted via the special PVH entry save the RSDP address set in the
>> boot information block in struct boot_params. This will enable Xen to
>> locate the RSDP at an arbitrary address.
>
On Tue, Nov 28, 2017 at 11:30:15AM +0100, Juergen Gross wrote:
> On 28/11/17 11:18, Roger Pau Monné wrote:
> > On Tue, Nov 28, 2017 at 10:43:59AM +0100, Juergen Gross wrote:
> >> In case the rsdp address in struct boot_params is specified don't try
> >> to find the table by searching, but take the
>>> On 28.11.17 at 11:17, wrote:
> Am 28.11.2017 um 10:46 schrieb Jan Beulich:
> On 28.11.17 at 10:12, wrote:
>>> In theory the BIOS would search for address space and won't find
>>> anything, so the hotplug operation should fail even before it reaches
>>> the kernel in the first place.
>> Ho
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 10:40
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
>
> >
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 28 November 2017 11:01
> To: 'Jan Beulich'
> Cc: Andrew Cooper ; Julien Grall
> ; xen-devel
> Subject: Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between intern
Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky:
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:
On 11/23/2017 03:11 AM, Christian König wrote:
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11/
flight 116603 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
>>> On 28.11.17 at 12:06, wrote:
> Yes, it appears that mmio_retry is only set when the underlying emulation
> returned X86EMUL_OKAY but not all reps were completed. If the underlying
> emulation did not return X86EMUL_RETRY then I can't figure out why
> vio->io_completion should need to be set
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 11:26
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
>
> >
On Mon, Nov 27, 2017 at 04:58:52PM +, Andrew Cooper wrote:
> On 27/11/17 15:41, Daniel Kiper wrote:
> > If it is possible we would like to have the Xen image higher than the
> > booloader put it and certainly do not overwrite the Xen code and data
> > during copy/relocation. Otherwise the Xen m
>>> On 28.11.17 at 12:32, wrote:
> I have a feeling that you can trigger this also when xen.efi
> is launched directly from EFI. However, this may require some
> fiddling with crashkernel values.
I don't think so, no - that case was specifically fixed already
(I've pointed at that commit in anoth
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 28 November 2017 11:31
> To: 'Jan Beulich'
> Cc: Andrew Cooper ; Julien Grall
> ; xen-devel
> Subject: Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between intern
Am 28.11.2017 um 11:53 schrieb Jan Beulich:
On 28.11.17 at 11:17, wrote:
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-246
version 2
x86: infinite loop due to missing PoD error checking
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-247
version 2
Missing p2m error checking in PoD code
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
Certa
>>> On 28.11.17 at 12:58, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 28 November 2017 11:31
>> To: 'Jan Beulich'
>> Cc: Andrew Cooper ; Julien Grall
>> ; xen-devel
>> Subject: Re: [Xen-devel] [PAT
On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
> >>> On 27.11.17 at 16:41, wrote:
> > If it is possible we would like to have the Xen image higher than the
> > booloader put it and certainly do not overwrite the Xen code and data
> > during copy/relocation. Otherwise the Xen may cras
On Tue, Nov 28, 2017 at 04:51:51AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 12:32, wrote:
> > I have a feeling that you can trigger this also when xen.efi
> > is launched directly from EFI. However, this may require some
> > fiddling with crashkernel values.
>
> I don't think so, no - that c
flight 72497 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72497/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like
72475
test-amd64-i386-am
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 November 2017 12:04
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> emulation
>
> >
>>> On 28.11.17 at 13:47, wrote:
> On Tue, Nov 28, 2017 at 04:51:51AM -0700, Jan Beulich wrote:
>> >>> On 28.11.17 at 12:32, wrote:
>> > I have a feeling that you can trigger this also when xen.efi
>> > is launched directly from EFI. However, this may require some
>> > fiddling with crashkernel v
On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 13:47, wrote:
> > On Tue, Nov 28, 2017 at 04:51:51AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.17 at 12:32, wrote:
> >> > I have a feeling that you can trigger this also when xen.efi
> >> > is launched directly fr
>>> On 28.11.17 at 14:53, wrote:
> On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
>> >>> On 28.11.17 at 13:47, wrote:
>> > Then all cases should be covered.
>>
>> I don't think that's going to be enough: Once Xen gets moved,
>> the area to exclude needs to be updated too.
>
> If th
A call to handle_hvm_io_completion() is needed for completing I/O
that requires external emulation. Such completion should be requested when
hvm_vcpu_io_need_completion() returns true after hvm_emulate_once() has
completed. This is indicative of the underlying I/O emulation having
returned X86EMUL_
flight 116610 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
116533
Tests whic
Hi,
On 16/11/17 12:02, Andre Przywara wrote:
> If the host GICv3 redistributor reports that the pending table cannot
> use shareable memory, we try to drop the cacheability attributes as
> well. However we fail horribly in doing computer science 101 bit
> masking, effectively clearing the whole re
On Tue, Nov 28, 2017 at 07:02:01AM -0700, Jan Beulich wrote:
> >>> On 28.11.17 at 14:53, wrote:
> > On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.17 at 13:47, wrote:
> >> > Then all cases should be covered.
> >>
> >> I don't think that's going to be enough: Once X
>>> On 28.11.17 at 13:41, wrote:
> On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
>> >>> On 27.11.17 at 16:41, wrote:
>> > If it is possible we would like to have the Xen image higher than the
>> > booloader put it and certainly do not overwrite the Xen code and data
>> > during cop
It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.
Signed-off-by: Stewart Hildebrand
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/dom
>>> On 18.10.17 at 10:27, wrote:
> Raw policy contains the actual values from H/W MSRs. PLATFORM_INFO msr
> needs to be read again because probe_intel_cpuid_faulting() records
> the presence of X86_FEATURE_CPUID_FAULTING but not the presence of msr
> itself (if cpuid faulting is not available).
I
flight 116592 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 115643
test-amd64-amd64-li
flight 116621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v14:
- Responded to more comments from Jan.
v13:
- Responded to more comments from Jan and Julien.
- Build-tested using ARM cross-compilation.
v12:
- Responded to mo
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44 +++
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
On Wed, Sep 20, 2017 at 04:13:43PM +0100, Wei Liu wrote:
>On Tue, Sep 19, 2017 at 11:06:26AM +0800, Lan Tianyu wrote:
>> Hi Wei:
>>
>> On 2017年09月18日 21:06, Wei Liu wrote:
>> > On Wed, Sep 13, 2017 at 12:52:47AM -0400, Lan Tianyu wrote:
>> >> This patch is to increase page pool size when max vcpu
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Co
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
guests looking at IF flag directly will always see it set, resulting
in 'ud2'.
Introduce SAVE_F
>>> On 18.10.17 at 10:27, wrote:
> New definitions provide a convenient way of accessing contents of
> VMX MSRs. They are separated into 5 logical blocks:
>
> 1. vmx: [VMX_BASIC, VMX_VMCS_ENUM]
> 2. VMX_PROCBASED_CTLS2
> 3. VMX_EPT_VPID_CAP
> 4. vmx_true_ctls: [VMX_TRUE_PINBASED_C
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -32,6 +32,37 @@ struct msr_domain_policy __read_mostly
> raw_msr_domain_policy,
> struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
> __read_mostly pv_max_msr_vcpu
>>> On 18.10.17 at 10:27, wrote:
> +static void __init calculate_hvm_max_vmx_policy(struct msr_domain_policy *dp)
> +{
> +if ( !cpu_has_vmx )
> +return;
> +
> +dp->vmx.basic.raw = host_msr_domain_policy.vmx.basic.raw;
> +
> +dp->vmx.pinbased_ctls.raw = ((uint64_t) VMX_PINBASED_
>>> On 18.10.17 at 10:27, wrote:
> With the new cpuid infrastructure there is a domain-wide struct cpuid
> policy and there is no need to pass a separate struct vcpu * into
> hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
> domain * instead and update callers.
>
> Signed-off-
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -124,6 +124,7 @@ static int update_domain_cpuid_info(struct domain *d,
> }
>
> recalculate_cpuid_policy(d);
> +recalculate_domain_msr_policy(d);
Considering the name of the other func
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -360,8 +360,10 @@ int init_vcpu_msr_policy(struct vcpu *v)
>
> int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> {
> +const struct domain *d = v->domain;
> const struct msr_d
Hi
On Sat, Nov 25, 2017 at 4:16 PM, Eduardo Habkost wrote:
> The existing has_dynamic_sysbus flag makes the machine accept
> every user-creatable sysbus device type on the command-line.
> Replace it with a list of allowed device types, so machines can
> easily accept some sysbus devices while rej
From: Tamas K Lengyel
Currently the built-in XSM policy only gets used if there is no other policy
specified during boot. In this patch we add a Kconfig option to specify to only
use built-in policy during boot. This is particularly important when booting
Xen through the shim to ensure the XSM po
On Tue, Nov 28, 2017 at 05:55:15PM +0100, Marc-André Lureau wrote:
[...]
> Hi
>
> On Sat, Nov 25, 2017 at 4:16 PM, Eduardo Habkost wrote:
> > The existing has_dynamic_sysbus flag makes the machine accept
> > every user-creatable sysbus device type on the command-line.
> > Replace it with a list o
On 11/28/2017 10:08 AM, Paul Durrant wrote:
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the
On 11/28/2017 01:06 PM, Tamas K Lengyel wrote:
From: Tamas K Lengyel
Currently the built-in XSM policy only gets used if there is no other policy
specified during boot. In this patch we add a Kconfig option to specify to only
use built-in policy during boot. This is particularly important when
On 11/28/2017 04:12 AM, Christian König wrote:
>
>
> How about the attached patch? It limits the newly added MMIO space to
> the upper 256GB of the address space. That should still be enough for
> most devices, but we avoid both issues with Xen dom0 as most likely
> problems with memory hotplug as
On 28/11/17 18:06, Tamas K Lengyel wrote:
> From: Tamas K Lengyel
>
> Currently the built-in XSM policy only gets used if there is no other policy
> specified during boot. In this patch we add a Kconfig option to specify to
> only
> use built-in policy during boot. This is particularly important
On 11/28/2017 02:05 PM, Andre Przywara wrote:
Hi,
Hi Andre,
Sorry someone I skipped that patch :/.
On 16/11/17 12:02, Andre Przywara wrote:
If the host GICv3 redistributor reports that the pending table cannot
use shareable memory, we try to drop the cacheability attributes as
well. However
Hi Stewart,
On 11/28/2017 02:42 PM, Stewart Hildebrand wrote:
It's not possible for an irq to be both below 16 and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.
Signed-off-by: Stewart Hildebrand
Whoops. Well spotted!
Reviewed-by: Julien Grall
Also
On Tue, Nov 28, 2017 at 12:00 PM, Andrew Cooper
wrote:
> On 28/11/17 18:06, Tamas K Lengyel wrote:
>> From: Tamas K Lengyel
>>
>> Currently the built-in XSM policy only gets used if there is no other policy
>> specified during boot. In this patch we add a Kconfig option to specify to
>> only
>>
Hi all,
Xen tree is going to branch at RC7. I don't want to branch when
master != staging, so please avoid committing new patches to staging now
to let master catch up with staging. Another announcement will be made
when the moratorium is lifted.
Cheers,
_
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
On 28/11/17 19:34, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without t
On Tue, Nov 28, 2017 at 11:34:42AM -0800, Maran Wilson wrote:
> This PoC patch enables Qemu to use that same entry point for booting KVM
> guests.
Nice. I do a a lot of -kernel boots in qemu/kvm for testing, and
speeding this further up would be great.
___
A fuzzer based on AFL and TriforceAFL discovered an assertion
violation in Xen 4.9.1.
The issue is that, when `opaque_out` is non-zero,
do_grant_table_op() assumes that the hypercall was preempted and a
continuation is generated. However, `opaque_out` also ends up being
non-zero if the guest calle
On Tue, Nov 28, 2017 at 10:43 AM, Juergen Gross wrote:
> In the non-EFI boot path the ACPI RSDP table is currently found via
> either EBDA or by searching through low memory for the RSDP magic.
> This requires the RSDP to be located in the first 1MB of physical
> memory. Xen PVH guests, however, g
flight 116635 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116635/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 116616 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 116614 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116614/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm broken in 116596
test-amd6
flight 116639 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 116635
Tests which
flight 116619 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116619/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail blocked in
116463
test-amd64-i386-xl-qemut-
flight 116645 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 116635
Tests which
flight 116620 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-xtf-amd64-amd64-1 49 xtf/test-hvm
flight 116650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5 hos
1 - 100 of 104 matches
Mail list logo
