On 03.02.2020 20:48, Andrew Cooper wrote:
> On 31/01/2020 16:44, Jan Beulich wrote:
>> TBD: In principle the caching here yields unnecessary the one used for
>> insn bytes (vio->mmio_insn{,_bytes}. However, to seed the cache
>> with the data SVM may have made available, we'd have to also
On 04.02.2020 18:19, Wei Liu wrote:
> On Tue, Feb 04, 2020 at 06:07:00PM +0100, Jan Beulich wrote:
>> On 04.02.2020 17:55, Wei Liu wrote:
>>> Signed-off-by: Wei Liu
>>> ---
>>> xen/arch/x86/e820.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/e820.c b
On 04.02.2020 18:34, Roger Pau Monne wrote:
> Import the functions and it's dependencies. Based on Linux 5.5, commit
> id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
>
> Signed-off-by: Roger Pau Monné
Thanks for going this route; two remarks / requests:
> --- a/xen/common/bitmap.c
> +++ b/xen/com
On 04.02.2020 18:34, Roger Pau Monne wrote:
> @@ -183,13 +193,27 @@ void nvmx_vcpu_destroy(struct vcpu *v)
> v->arch.hvm.vmx.vmwrite_bitmap = NULL;
> }
> }
> -
> +
> +void vcpu_relinquish_resources(struct vcpu *v)
static (which would be easy to add while committing, if no other
nee
On 04.02.2020 18:34, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -596,6 +596,13 @@ static void update_msrbitmap(struct vcpu *v, uint32_t
> shadow_ctrl)
>v->arch.hvm.vmx.msr_bitmap->write_high,
>sizeof(msr_bitma
Am Dienstag, 4. Februar 2020, 15:18:53 CET schrieb Jürgen Groß:
> On 04.02.20 15:07, Dietmar Hahn wrote:
> > Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
> >> On 30/01/2020 13:03, Dietmar Hahn wrote:
> >>> Hi,
> >>>
> >>> we use SLES12 with kernel-default-4.12.14-95.45.1.x86_64
On Tue, Feb 04, 2020 at 09:49:37PM +, Igor Druzhinin wrote:
> The value of the counter represents the number of nanoseconds
> since host boot. That means the correct frequency is always 1GHz.
>
> This inconsistency caused time to go slower in PV shim on most
> platforms.
>
> Signed-off-by: Ig
On Tue, Feb 04, 2020 at 09:49:36PM +, Igor Druzhinin wrote:
> Similarly to S3, platform time needs to be saved on guest suspend
> and restored on resume respectively. This should account for expected
> jumps in PV clock counter value after resume. time_suspend/resume()
> are safe to use in PVH
On 05.02.20 10:03, Dietmar Hahn wrote:
Am Dienstag, 4. Februar 2020, 15:18:53 CET schrieb Jürgen Groß:
On 04.02.20 15:07, Dietmar Hahn wrote:
Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
On 30/01/2020 13:03, Dietmar Hahn wrote:
Hi,
we use SLES12 with kernel-default-4.12.
An assertion in libxl__domain_make():
'soft_reset || *domid == INVALID_DOMID'
does not hold true for stub domain creation, where soft_reset is false
but the passed in domid == 0. This is easily fixed by changing the
initializer in libxl__spawn_stub_dm().
Fixes: 75259239d85d ("libxl_create: make
First a small fix to halfway recent security related changes, and
then some cleanup noticed on the way as likely desirable.
1: fix off-by-one in amd_iommu_get_paging_mode() callers
2: drop redundant code
3: replace a few literal numbers
Jan
___
Xen-dev
amd_iommu_get_paging_mode() expects a count, not a "maximum possible"
value. Prior to b4f042236ae0 dropping the reference, the use of our mis-
named "max_page" in amd_iommu_domain_init() may have lead to such a
misunderstanding.
Also replace a literal 4 by an expression tying it to a wider use
con
The level 1 special exit path is unnecessary in iommu_pde_from_dfn() -
the subsequent code takes care of this case quite fine.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -198,12 +198,6 @@ static int iommu_pde_from_dfn
Introduce IOMMU_PDE_NEXT_LEVEL_{MIN,MAX} to replace literal 1, 6, and 7
instances. While doing so replace two uses of memset() by initializers.
Signed-off-by: Jan Beulich
---
TBD: We should really honor the hats field of union
amd_iommu_ext_features, but the specification (or at least the
On 03.02.2020 15:43, Andrew Cooper wrote:
> We currently have amd-iommu-defs.h, amd-iommu-proto.h and amd-iommu.h, and no
> references outside of the AMD IOMMU driver.
>
> Keep iommu-defs.h as is, but merge amd-iommu.h and amd-iommu-proto.h to just
> iommu.h, and move them both into drivers/passth
On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> At very least it's more robust this way; the algorithm is also less
> "magic". We just had a long discussion this morning trying to re-create
> the logic for why "Remove MFN 0" was sufficient to prevent this issue,
> and even then David was
On 03.02.2020 15:43, Andrew Cooper wrote:
> @@ -85,16 +85,14 @@ static void flush_command_buffer(struct amd_iommu *iommu)
> loop_count = 1000;
> do {
> status = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> -comp_wait = get_field_from_reg_u32(status,
> -
On 05.02.2020 10:50, David Woodhouse wrote:
> On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
>> At very least it's more robust this way; the algorithm is also less
>> "magic". We just had a long discussion this morning trying to re-create
>> the logic for why "Remove MFN 0" was sufficient
Add the new library libxenhypfs for access to the hypervisor filesystem.
Signed-off-by: Juergen Gross
---
V1:
- rename to libxenhypfs
- add xenhypfs_write()
V3:
- major rework due to new hypervisor interface
- add decompression capability
V4:
- add dependency to libz in pkgconfig file (Wei Liu)
Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.
Signed-off-by: Juergen Gross
---
V3:
- store data in gzip format
- use binfile mechanism to create data file
- move code to kernel.c
---
.gitignore |
Provide version and compile information in /buildinfo/ node of the
Xen hypervisor file system. As this information is accessible by dom0
only no additional security problem arises.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V3:
- new patch
V4:
- add __read_mostly annotations (Jan
Add the xenfs tool for accessing the hypervisor filesystem.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
V1:
- rename to xenhypfs
- don't use "--" for subcommands
- add write support
V2:
- escape non-printable characters per default with cat subcommand
(Ian Jackson)
- add -b option to c
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
This is a first implementation of that idea adding the basic
functionality to hypervisor and tools side. The interface to any
us
On the 2019 Xen developer summit there was agreement that the Xen
hypervisor should gain support for a hierarchical name-value store
similar to the Linux kernel's sysfs.
In the beginning there should only be basic support: entries can be
added from the hypervisor itself only, there is a simple hyp
Add the infrastructure for the hypervisor filesystem.
This includes the hypercall interface and the base functions for
entry creation, deletion and modification.
In order not to have to repeat the same pattern multiple times in case
adding a new node should BUG_ON() failure, the helpers for addin
Add a new script xen/tools/binfile for including a binary file at build
time being usable via a pointer and a size variable in the hypervisor.
Make use of that generic tool in xsm.
Signed-off-by: Juergen Gross
---
V3:
- new patch
V4:
- add alignment parameter (Jan Beulich)
- use .Lend instead o
Add support to read and modify values of hypervisor runtime parameters
via the hypervisor file system.
As runtime parameters can be modified via a sysctl, too, this path has
to take the hypfs rw_lock as writer.
For custom runtime parameters the resulting parameter value needs to
be stored in a st
flight 146739 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146739/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f7fb9a0aa9fbb81292e1626ce40340d3f6d8d505
baseline version:
xen 41d8
On 03.02.2020 15:43, Andrew Cooper wrote:
> The MMIO registers as already byte offsets. By masking out the reserved bits
> suitably in guest_iommu_mmio_write64(), we can use the values directly,
> instead of masking/shifting on every use.
I guess it's unclear whether such masking matches real har
Hi,
On 05/02/2020 09:50, David Woodhouse wrote:
On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
At very least it's more robust this way; the algorithm is also less
"magic". We just had a long discussion this morning trying to re-create
the logic for why "Remove MFN 0" was sufficient to
Ping?
On Mon, Feb 03, 2020 at 02:21:08PM +0100, Roger Pau Monné wrote:
> On Mon, Feb 03, 2020 at 01:44:06PM +0100, Sander Eikelenboom wrote:
> > On 03/02/2020 13:41, Roger Pau Monné wrote:
> > > On Mon, Feb 03, 2020 at 01:30:55PM +0100, Sander Eikelenboom wrote:
> > >> On 03/02/2020 13:23, Roger P
On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
> > +/* Pages from the boot allocator need to pass through
> > init_heap_pages() */
> > +if ( unlikely(!pg->count_info) )
>
> ... while I think this check may be fine here, no similar one
> can be used in free_domheap_pages(), yet page
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> Hi,
>
> On 05/02/2020 09:50, David Woodhouse wrote:
> > On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> > > At very least it's more robust this way; the algorithm is also less
> > > "magic". We just had a long discussion this morn
On 03.02.2020 15:43, Andrew Cooper wrote:
> --- a/xen/drivers/passthrough/amd/iommu_cmd.c
> +++ b/xen/drivers/passthrough/amd/iommu_cmd.c
> @@ -24,16 +24,14 @@ static int queue_iommu_command(struct amd_iommu *iommu,
> u32 cmd[])
> {
> uint32_t tail, head;
>
> -tail = iommu->cmd_buffer.
flight 146732 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 146563
On Wed, Feb 05, 2020 at 09:37:24AM +, Paul Durrant wrote:
> An assertion in libxl__domain_make():
>
> 'soft_reset || *domid == INVALID_DOMID'
>
> does not hold true for stub domain creation, where soft_reset is false
> but the passed in domid == 0. This is easily fixed by changing the
> initi
On 05.02.2020 11:24, David Woodhouse wrote:
> On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
>>> +/* Pages from the boot allocator need to pass through
>>> init_heap_pages() */
>>> +if ( unlikely(!pg->count_info) )
>>
>> ... while I think this check may be fine here, no similar one
> -Original Message-
> From: Anthony PERARD
> Sent: 05 February 2020 10:47
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Ian Jackson
> ; Wei Liu ; Roger Pau Monné
>
> Subject: Re: [PATCH] libxl: fix assertion failure in stub domain creation
>
> On Wed, Feb 05, 2020 at 09:37:
On 05.02.2020 11:11, Juergen Gross wrote:
> Add a new script xen/tools/binfile for including a binary file at build
> time being usable via a pointer and a size variable in the hypervisor.
>
> Make use of that generic tool in xsm.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
___
On 23.01.2020 12:36, Jan Beulich wrote:
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
>^ ~~
flight 146738 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
Hi Roger,
Sorry, I haven't been able to follow up on testing yet.
(I have some longer running task for which I need some services on the box,
so testing and rebooting is needed.)
Could be tomorrow, but could also be this weekend before I will come around to
the testing and reporting back.
--
Sa
On 04.02.2020 16:36, Wei Liu wrote:
> @@ -215,18 +220,19 @@ static void init_evtchn(void)
> rc = xen_hypercall_set_evtchn_upcall_vector(this_cpu(vcpu_id),
> evtchn_upcall_vector);
> if ( rc )
> -panic("Unable to set evtchn upcall ve
On 04.02.2020 16:36, Wei Liu wrote:
> This allows us to set aside some address space for executable mapping.
> This fixed map range starts from XEN_VIRT_END so that it is within reach
> of the .text section.
>
> Shift the percpu stub range and shrink livepatch range accordingly.
>
> Signed-off-by
On 04.02.2020 16:37, Wei Liu wrote:
> These functions will be used later to make hypercalls to Hyper-V.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://li
On Wed, Feb 05, 2020 at 12:03:00PM +0100, Sander Eikelenboom wrote:
> Hi Roger,
>
> Sorry, I haven't been able to follow up on testing yet.
> (I have some longer running task for which I need some services on the box,
> so testing and rebooting is needed.)
> Could be tomorrow, but could also be
Hi Jan,
On 04/02/2020 15:13, Jan Beulich wrote:
On 04.02.2020 14:51, Julien Grall wrote:
On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
At the moment, assign_pages() relies on PG_state_inuse to be 0. This
makes the code slightly more difficult to understand
On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
> Yet, as you say elsewhere, whether an MFN has an
> entry in frame_table[] is entirely unclear, so permitting boot-
> allocator pages to be freed via alloc_domheap_pages() nevertheless
> still doesn't look any better an idea to me.
Hm, I don't
An assertion in libxl__domain_make():
'soft_reset || *domid == INVALID_DOMID'
does not hold true for stub domain creation, where soft_reset is false
but the passed in domid == 0. This is easily fixed by changing the
initializer in libxl__spawn_stub_dm().
NOTE: The comment for XEN_DOMCTL_createdo
On Wed, Feb 05, 2020 at 10:50:46AM +, Durrant, Paul wrote:
> > From: Anthony PERARD
> > On Wed, Feb 05, 2020 at 09:37:24AM +, Paul Durrant wrote:
> > >
> > > -sdss->pvqemu.guest_domid = 0;
> > > +sdss->pvqemu.guest_domid = INVALID_DOMID;
> >
> > How this works? INVALID_DOMID seems
On Wed, Feb 05, 2020 at 11:24:12AM +, Paul Durrant wrote:
> An assertion in libxl__domain_make():
>
> 'soft_reset || *domid == INVALID_DOMID'
>
> does not hold true for stub domain creation, where soft_reset is false
> but the passed in domid == 0. This is easily fixed by changing the
> initi
On 05.02.2020 12:24, Paul Durrant wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -42,7 +42,8 @@
>
> /*
> * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> - * If it is specified as zero, an id is auto-allocated and returned.
> + * If it i
On Wed, Feb 05, 2020 at 11:24:12AM +, Paul Durrant wrote:
> NOTE: The comment for XEN_DOMCTL_createdomain in domctl.h is changed to
> reflect reality.
Surely, this change deserve to be in its own patch, isn't it?
--
Anthony PERARD
___
Xen-de
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> However, I don't like the idea of relying on count_info == 0. Indeed,
> there are valid case where count_info == 0 because it means the page is
> inuse (PCC_state_inuse).
>
> It might be best if we introduce a new page state that would be
On 03.02.2020 17:12, Tamas K Lengyel wrote:
> @@ -4414,6 +4424,40 @@ static int hvm_allow_get_param(struct domain *d,
> return rc;
> }
>
> +static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
> +{
> +int rc;
> +
> +rc = hvm_allow_get_param(d, index);
> +i
On Wed, Feb 05, 2020 at 11:29:30AM +, Anthony PERARD wrote:
> On Wed, Feb 05, 2020 at 11:24:12AM +, Paul Durrant wrote:
> > NOTE: The comment for XEN_DOMCTL_createdomain in domctl.h is changed to
> > reflect reality.
>
> Surely, this change deserve to be in its own patch, isn't it?
On Wed, Feb 05, 2020 at 09:12:50AM +0100, Jan Beulich wrote:
> On 04.02.2020 18:19, Wei Liu wrote:
> > On Tue, Feb 04, 2020 at 06:07:00PM +0100, Jan Beulich wrote:
> >> On 04.02.2020 17:55, Wei Liu wrote:
> >>> Signed-off-by: Wei Liu
> >>> ---
> >>> xen/arch/x86/e820.c | 2 +-
> >>> 1 file change
flight 146737 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On Tue, Feb 04, 2020 at 08:29:38PM +, Andrew Cooper wrote:
> It turns out that a bug (since forever) in Xen causes XSAVE records to have
> non-architectural behaviour on xsave-capable hardware, when a PV guest has not
> touched the state.
>
> In such a case, the data record returned from Xen i
On Wed, Feb 05, 2020 at 11:11:37AM +0100, Juergen Gross wrote:
> Add the new library libxenhypfs for access to the hypervisor filesystem.
>
> Signed-off-by: Juergen Gross
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
htt
flight 146733 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
test-amd64-i386-xl
On Wed, Feb 05, 2020 at 12:12:30PM +0100, Jan Beulich wrote:
> On 04.02.2020 16:36, Wei Liu wrote:
> > @@ -215,18 +220,19 @@ static void init_evtchn(void)
> > rc = xen_hypercall_set_evtchn_upcall_vector(this_cpu(vcpu_id),
> > evtchn_upcall_vecto
flight 146735 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
On 05.02.2020 13:09, Wei Liu wrote:
> On Wed, Feb 05, 2020 at 12:12:30PM +0100, Jan Beulich wrote:
>> On 04.02.2020 16:36, Wei Liu wrote:
>>> @@ -254,14 +260,20 @@ static void __init setup(void)
>>> XEN_LEGACY_MAX_VCPUS);
>>> }
>>>
>>> -init_evtchn();
>>> +BUG_ON(init
On Tue, Feb 04, 2020 at 04:02:38PM +, Xia, Hongyan wrote:
[...]
> > Keep in mind that accessing the union {pv, hvm} before knowing the
> > exact variant is dangerous.
> >
> > Because mapcache is initialised for PV only, so it should be freed
> > for
> > PV only. I think you need to put it to p
Ilja has reported a couple of issues which were on the boundary of
needing an XSA, due to some vagueness of the statements resulting
from XSA-77. The first 3 patches here address these reports, after
having settled within the Security Team that we can't find anyone /
anything actually being potenti
A malicious guest given permission to invoke XENPF_efi_runtime_call may
play with the strings underneath Xen sizing them and copying them in.
Guard against this by re-checking the copyied in data for consistency
with the initial sizing. At the same time also check that the actual
copy-in is in fact
Commit 1f4eb9d27d0e ("EFI: fix getting EFI variable list on some
systems") switched to using the caller provided size for the copy-out
without making sure the copied buffer is properly scrubbed.
Reported-by: Ilja Van Sprundel
Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
--- a/xen/comm
There are hypercall handling paths (EFI ones are what this was found
with) needing to allocate buffers of a caller specified size. This is
generally fine, as our page allocator enforces an upper bound on all
allocations. However, certain extremely large sizes could, when adding
in allocator overhea
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range.
Signed-off-by: Jan Beulich
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -187,13 +187,17 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xe
uint32_t *status, *ptr;
mfn_t mfn;
... when plain xzalloc() (which is more type safe) does.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -969,7 +969,7 @@ static void gicv2_add_v2m_frame_to_list(
nr_spis, V2M_MAX_SPI - V2M_MIN_SPI + 1);
/* Allocate an entry to record n
Checking the result of a multiplication against a certain limit has no
sufficient implication on the original value's range. In the case here
it is in particular problematic that while handling the domctl we do
if ( copy_from_guest(info->vdistance, uinfo->vdistance,
nr
On 05.02.2020 14:11, Jan Beulich wrote:
> Ilja has reported a couple of issues which were on the boundary of
> needing an XSA, due to some vagueness of the statements resulting
> from XSA-77. The first 3 patches here address these reports, after
> having settled within the Security Team that we can
On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan Beulich wrote:
> On 04.02.2020 18:34, Roger Pau Monne wrote:
> > Import the functions and it's dependencies. Based on Linux 5.5, commit
> > id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
> >
> > Signed-off-by: Roger Pau Monné
>
> Thanks for going this
On 05.02.2020 14:21, Roger Pau Monné wrote:
> On Wed, Feb 05, 2020 at 09:46:25AM +0100, Jan Beulich wrote:
>> On 04.02.2020 18:34, Roger Pau Monne wrote:
>>> Import the functions and it's dependencies. Based on Linux 5.5, commit
>>> id d5226fa6dbae0569ee43ecfc08bdcd6770fc4755.
>>>
>>> Signed-off-by
On 05.02.2020 12:24, Julien Grall wrote:
> Hi Jan,
>
> On 04/02/2020 15:13, Jan Beulich wrote:
>> On 04.02.2020 14:51, Julien Grall wrote:
>>>
>>>
>>> On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
> At the moment, assign_pages() relies on PG_state_inuse
On 05.02.2020 12:23, David Woodhouse wrote:
> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>> Yet, as you say elsewhere, whether an MFN has an
>> entry in frame_table[] is entirely unclear, so permitting boot-
>> allocator pages to be freed via alloc_domheap_pages() nevertheless
>> still d
flight 146742 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 144861
build-arm64-xsm
Am Mittwoch, 5. Februar 2020, 10:31:37 CET schrieb Jürgen Groß:
> On 05.02.20 10:03, Dietmar Hahn wrote:
> > Am Dienstag, 4. Februar 2020, 15:18:53 CET schrieb Jürgen Groß:
> >> On 04.02.20 15:07, Dietmar Hahn wrote:
> >>> Am Freitag, 31. Januar 2020, 22:59:19 CET schrieb Igor Druzhinin:
> On
On Tue, Feb 04, 2020 at 03:36:59PM +, Wei Liu wrote:
> Hyper-V uses a technique called overlay page for its hypercall page. It
> will insert a backing page to the guest when the hypercall functionality
> is enabled. That means we can use a page that is not backed by real
> memory for hypercall
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.6-rc1-tag
xen: branch for v5.6-rc1
It contains:
- a fix of a bug introduced in 5.5 for the Xen gntdev driver
- a fix of the Xen balloon driver when running on ancient Xen versions
-
On Wed, Feb 5, 2020 at 4:40 AM Jan Beulich wrote:
>
> On 03.02.2020 17:12, Tamas K Lengyel wrote:
> > @@ -4414,6 +4424,40 @@ static int hvm_allow_get_param(struct domain *d,
> > return rc;
> > }
> >
> > +static int hvm_get_param(struct domain *d, uint32_t index, uint64_t *value)
> > +{
> > +
> On 05.02.2020 12:23, David Woodhouse wrote:
>> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>>> Yet, as you say elsewhere, whether an MFN has an
>>> entry in frame_table[] is entirely unclear, so permitting boot-
>>> allocator pages to be freed via alloc_domheap_pages() nevertheless
>>
Hi Jan,
On 05/02/2020 13:36, Jan Beulich wrote:
On 05.02.2020 12:24, Julien Grall wrote:
Hi Jan,
On 04/02/2020 15:13, Jan Beulich wrote:
On 04.02.2020 14:51, Julien Grall wrote:
On 04/02/2020 13:40, Jan Beulich wrote:
On 04.02.2020 14:33, Julien Grall wrote:
At the moment, assign_pages()
Hi Jan,
On 05/02/2020 13:16, Jan Beulich wrote:
... when plain xzalloc() (which is more type safe) does.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -969,7 +969,7 @@ static void gicv2_add_v2m_frame_to_list(
Hi Jan,
On 05/02/2020 13:16, Jan Beulich wrote:
This is more robust than the raw xmalloc_bytes().
Also add a sanity check on the input page range.
It feels to me that the commit message/title should focus on the sanity
check. The xmalloc_array() is just a cleanup is "less important".
Argua
On Wed, Feb 05, 2020 at 03:04:16PM +0100, Roger Pau Monné wrote:
[...]
> > +static void __init setup_hypercall_page(void)
> > +{
> > +union hv_x64_msr_hypercall_contents hypercall_msr;
> > +union hv_guest_os_id guest_id;
> > +unsigned long mfn;
> > +
> > +BUILD_BUG_ON(HV_HYP_PAGE_SH
On Wed, Feb 05, 2020 at 03:00:24PM +, Wei Liu wrote:
> On Wed, Feb 05, 2020 at 03:04:16PM +0100, Roger Pau Monné wrote:
> [...]
> > > +static void __init setup_hypercall_page(void)
> > > +{
> > > +union hv_x64_msr_hypercall_contents hypercall_msr;
> > > +union hv_guest_os_id guest_id;
>
On Wed, Feb 05, 2020 at 02:17:02PM +0100, Jan Beulich wrote:
> Checking the result of a multiplication against a certain limit has no
> sufficient implication on the original value's range. In the case here
> it is in particular problematic that while handling the domctl we do
>
> if ( copy_fr
Hi Thomas
On 11/25/19 11:27, Qais Yousef wrote:
> Changes in v2:
> * Add 2 new patches that create smp_shutdown_nonboot_cpus() to be used
> in machine_shutdown() in ia64, arm and arm64
> * Use proper kernel-doc for the newly introduced functions
> * Renamed a function
>
> -Original Message-
> From: Wei Liu On Behalf Of Wei Liu
> Sent: 04 February 2020 15:37
> To: Xen Development List
> Cc: Durrant, Paul ; Michael Kelley
> ; Wei Liu ; Wei Liu
> ; Jan Beulich ; Andrew Cooper
> ; Roger Pau Monné
> Subject: [PATCH v7 05/10] x86/hyperv: setup hypercall page
flight 146744 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146744/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usually get:
(it's easily reproducible)
(XEN) [ 342.528305] livepatch: lp: CPU8 - IPIing the other 15 CPUs
(XEN) [ 342.558340] livepatch: lp: Timed out on semaph
Ping?
Just want to make sure this doesn't go under the radar.
Thanks, Roger.
On Mon, Jan 27, 2020 at 07:11:08PM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series aims to improve the TLB flush times when running
> nested Xen, and it's specially beneficial when running in shim mode.
Ping.
On Tue, 2020-01-28 at 13:50 +, Hongyan Xia wrote:
> From: Wei Liu
>
> We are going to switch to using domheap page for page tables.
> A new set of APIs is introduced to allocate and free pages of page
> tables based on mfn instead of the xenheap direct map address. The
> allocation and
On 05.02.20 17:03, Sergey Dyasli wrote:
Hello,
I'm currently investigating a Live-Patch application failure in core-
scheduling mode and this is an example of what I usually get:
(it's easily reproducible)
(XEN) [ 342.528305] livepatch: lp: CPU8 - IPIing the other 15 CPUs
(XEN) [ 34
On 05.02.2020 15:34, Julien Grall wrote:
> On 05/02/2020 13:16, Jan Beulich wrote:
>> This is more robust than the raw xmalloc_bytes().
>>
>> Also add a sanity check on the input page range.
>
> It feels to me that the commit message/title should focus on the sanity
> check. The xmalloc_array() i
On 05.02.2020 17:14, Roger Pau Monné wrote:
> Ping?
>
> Just want to make sure this doesn't go under the radar.
It's safely sitting in my to-be-looked-at folder, but there's
way too much else to look after to get to it, yet.
Jan
___
Xen-devel mailing
On 05.02.2020 17:25, Xia, Hongyan wrote:
> Ping.
Sorry, there's just too much else also needing attention. I'm
doing what I can review-wise, and I assume some others do so,
too. You're very welcome to help with the review load.
Jan
> On Tue, 2020-01-28 at 13:50 +, Hongyan Xia wrote:
>> From:
These are believed-unused, and the underlying infrastructure is about to be
rewritten completely.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Marek Marczykowski-Górecki
---
tools/python/xen/lowlevel/xc/xc.c | 98 ---
1 file changed, 98
1 - 100 of 122 matches
Mail list logo
