When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope
flight 112772 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
112655
find_next_rmrr(base) is used to find the lowest RMRR ending above base
but below 4G. Current method couldn't cover the following situation:
a. two rmrr exist, small gap between them
b. pci_mem_start and mem_resource.base is below the first rmrr.base
c. find_next_rmrr(pci_mem_start) will find the
Hi,
On Aug 18 2017 16:23, Oleksandr Andrushchenko wrote:
>> You mean that any alsa-lib or libpulse applications run on Dom0 as a
>> backend driver for the frontend driver on DomU?
>>
> No, the sound backend [1] is a user-space application (ALSA/PulseAudio
> client)
> which runs as a Xen
On 17-08-21 18:13:07, Chao Peng wrote:
>
> > int libxl_psr_cat_get_info(libxl_ctx *ctx, libxl_psr_cat_info **info,
> > int *nr, unsigned int lvl)
> > {
> > GC_INIT(ctx);
> > int rc;
> > -int i = 0, socketid, nr_sockets;
> > -libxl_bitmap socketmap;
On 17-08-21 18:12:18, Chao Peng wrote:
>
> > * mode: C
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 6e80d36..10d317b 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -977,6 +977,7 @@ libxl_psr_cbm_type =
On 17-08-21 18:14:49, Chao Peng wrote:
>
> >
> > -static void libxl__psr_cat_log_err_msg(libxl__gc *gc, int err)
> > +static void libxl__psr_alloc_log_err_msg(libxl__gc *gc,
> > + int err,
> > + libxl_psr_cbm_type
On Mon, Aug 21, 2017 at 4:38 AM, Andrii Anisov wrote:
>
> On 18.08.17 23:43, Meng Xu wrote:
>>
>> Sure. The workload we used in the paper is mainly the cpu-intensive task.
>> We first calibrate a busy-loop of multiplications that runs for 1ms.
>> Then for a task that
These routines are first called via CPU_UP_PREPARE notifier by
the BSP and then by the booting ASP from vmx_cpu_up()/_svm_cpu_up().
Avoid the unnecessary second call. Because BSP doesn't go through
CPU_UP_PREPARE it is a special case. We pass 'bsp' flag to newly
added _vmx_cpu_up() (just like
On Mon, Aug 21, 2017 at 4:16 AM, Andrii Anisov wrote:
>
> On 21.08.17 11:07, Andrii Anisov wrote:
>>
>> Hello Meng Xu,
>>
>>
>> On 18.08.17 23:43, Meng Xu wrote:
>>>
>>> The Section 4.1 and 4.2 in [1] explained the whole experiment steps.
>>> If you have any question or
On Mon, Aug 21, 2017 at 4:07 AM, Andrii Anisov wrote:
>
> Hello Meng Xu,
>
>
> On 18.08.17 23:43, Meng Xu wrote:
>>
>> The Section 4.1 and 4.2 in [1] explained the whole experiment steps.
>> If you have any question or confusion on a specific step, please feel
>> free to
Long pressed key could not show right in XEN vncviewer after tigervnc client
changed the way how to send repeat keys, from "Down Up Down Up ..." to "Down
Down ... Up". By enable EV_REP bit here, XEN keyboard device will trigger
default auto repeat process from input subsystem, and make auto
flight 112799 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112799/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2
flight 112767 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
110906
On Wed, 26 Jul 2017, Owen Smith wrote:
> Writes "feature-raw-pointer" during init to indicate the backend
> can pass raw unscaled values for absolute axes to the frontend.
> Frontends set "request-raw-pointer" to indicate the backend should
> not attempt to scale absolute values to console size.
>
Anthony,
The code looks good. I tested this patch with Linux guests and seems to
work OK, can you also confirm?
One comment below.
On Wed, 26 Jul 2017, Owen Smith wrote:
> Avoid the unneccessary calls through the input-legacy.c file by
> using the qemu_input_handler_*() calls directly. This
flight 112796 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112796/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2
On Mon, 21 Aug 2017, Ross Lagerwall wrote:
> When the guest writes to the RTC, Xen emulates it and broadcasts a
> TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP message when this happens
> rather than ignoring it so that something useful can be done with the
> information.
Are there any handlers of the
On Fri, 11 Aug 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
and applied
> ---
> xen/arch/arm/vgic-v3.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git
On Fri, 11 Aug 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
and applied
> ---
> xen/arch/arm/domain.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git
On Fri, 11 Aug 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
and applied
> ---
> xen/arch/arm/vtimer.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git
On Sat, 19 Aug 2017, Zhongze Liu wrote:
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file". See:
>
> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03047.html
>
> Then plan is to use XENMEM_add_to_physmap_batch to map the shared
As Xen now supports SMCCC, we can enable this feature to tell
guests that it is safe to call generic SMCs and HVCs.
Signed-off-by: Volodymyr Babchuk
---
xen/common/kernel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/common/kernel.c
PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:
- Generic handler checks that 64 bit calls can be made only by
64 bit guests.
- SMCCC requires that 64-bit handler should support both 32 and 64 bit
calls even if they originate
On Tue, 15 Aug 2017, Lan Tianyu wrote:
> Hi Anthony:
>
> On 2017年08月12日 02:04, Anthony PERARD wrote:
> > On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote:
> >> From: Chao Gao
> >>
> >> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
> >>
This feature indicates that hypervisor is compatible with ARM
SMC calling convention. Hypervisor will not inject an undefined
instruction exception if an invalid SMC function were called and
will not crash a domain if an invlalid HVC functions were called.
Signed-off-by: Volodymyr Babchuk
smccc.h provides definitions to construct SMC call function number according
to SMCCC. We don't need multiple definitions for one thing, and definitions
in smccc.h are more generic than ones used in psci.h.
So psci.h will only provide function codes, while whole SMC function
identifier will be
This patch adds generic definitions used in ARM SMC call convention.
Those definitions was taken from linux header arm-smccc.h, extended
and formatted according to XEN coding style.
They can be used by both SMCCC clients (like PSCI) and by SMCCC
servers (like vPSCI or upcoming generic SMCCC
SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to different
firmware functions. Thus, for example, PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides
PSCI is part of HVC/SMC interface, so it should be handled in
appropriate place: `vsmc.c`. This patch just moves PSCI
handler calls from `traps.c` to `vsmc.c`.
Older PSCI 0.1 uses SMC function identifiers in range that is
resereved for exisings APIs (ARM DEN 0028B, page 16), while newer
PSCI 0.2
This patch adds definition HSR_XXC_IMM_MASK. It can be used to extract
immediate value for trapped HVC32, HVC64, SMC64, SVC32, SVC64 instructions,
as described at ARM ARM (ARM DDI 0487B.a pages D7-2270, D7-2272).
Signed-off-by: Volodymyr Babchuk
---
Trapped SMC instruction can fail condition check on ARMv8 arhcitecture
(ARM DDI 0487B.a page D7-2271). So we need to check if condition was meet.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/traps.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Added type xen_uuid_t. This type represents UUID as an array of 16
bytes in big endian format.
Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:
XEN_DEFINE_UUID(00112233, 4455, 6677, 8899, aabbccddeeff)
will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
There are standard functions set_user_reg() and get_user_reg(). We can
use them in PSCI_SET_RESULT()/PSCI_ARG() macroses instead of relying on
CONFIG_ARM_64 definition.
Signed-off-by: Volodymyr Babchuk
---
* Added space into reg,n
* Used 32-bit constant tin
Hello all,
v4:
* Added patch with public definitiod for xen_uuid_t
* Added patch with immediate value mask for SMC, HVC and SVC
* Added patch with header smccc.h (generic SMCCC definitions)
* Added patches that add and enable XENFEAT_ARM_SMCCC_supported
* Removed patch that added
On Mon, Aug 21, 2017 at 12:30 PM, Boris Ostrovsky
wrote:
>
> Adding maintainer (Dmitry).
I can't seem to find the original in my mailbox nor in patchwork. Can
you please resend?
>
>
> -boris
>
> On 08/21/2017 11:41 AM, Liang Yan wrote:
> > Long pressed key could not
On Fri, 11 Aug 2017, Julien Grall wrote:
> This is a left over of before the P2M code was reworked. So drop it.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 4
> 1 file changed, 4 deletions(-)
On Tue, 8 Aug 2017, Julien Grall wrote:
> Xen allows shared mapping to be Normal inner-cacheable with any inner cache
> allocation strategy and no restriction of the outer-cacheability.
>
> However, Xen is always mapping those region Normal Inner Write-Back
> Outer Write-Back Inner-shareable. Per
Adding maintainer (Dmitry).
-boris
On 08/21/2017 11:41 AM, Liang Yan wrote:
> Long pressed key could not show right in XEN vncviewer after tigervnc
> client changed the way how to send repeat keys, from "Down Up Down Up
> ..." to "Down Down Dow." By enable EV_REP bit here, XEN keyboard
> device
flight 112763 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs.
Many definitions can be moved from xen/grant_table.h to
common/grant_table.c now, as they are no longer used in other sources.
Signed-off-by: Juergen Gross
---
xen/common/grant_table.c | 81 +++-
xen/include/xen/grant_table.h | 86
Today a guest can get the maximum grant table frame number for the
currently selected grant table interface version (1 or 2) only. Add
a new grant table operation to get the limits of both variants in
order to give the guest an opportunity to select the version serving
its needs best.
Background
The boot parameter gnttab_max_nr_frames has been deprecated in Xen 4.5.
Remove it now.
Signed-off-by: Juergen Gross
---
xen/common/grant_table.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/xen/common/grant_table.c
Currently Linux has no support for grant v2 as this would reduce the
maximum number of active grants by a factor of 2 compared to v1,
because the number of possible grants are limited by the allowed number
of grant frames and grant entries of v2 need twice as much bytes as
those of v1.
The number of grants a domain can setup is limited by the maximum
number of grant frames it is allowed to use. Today the limit is the
same regardless whether the domain uses grant v1 or v2. Using v2
will therefor be a disadvantage for the domain as only half the
number of grants compared to v1 can
The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.
This at once fixes a bug in the arm code which didn't unlock the grant
table in error case.
On Mon, Aug 21, 2017 at 11:07:39AM +0100, Julien Grall wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.10 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use
This run is configured for baseline tests only.
flight 72000 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72000/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fa74dd2217aebe6930890e55d58d35e639b18c2e
baseline
flight 112759 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 host-install(4)broken REGR. vs. 112664
Hi Jan,
On 21/08/17 14:49, Jan Beulich wrote:
On 17.08.17 at 12:30, wrote:
On 16/08/17 19:33, Boris Ostrovsky wrote:
.. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).
We keep track of the first unscrubbed
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Reduce the scope of the TODO by squashing single-page stuff with
> multi-page one. Next target is to use large pages whenever
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> Reduce the scope of the TODO by squashing single-page stuff with
> multi-page one. Next target is to use large pages whenever
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> The hardware domains require IOMMU to be used in the most cases and
> a decision to use it is made at hardware domain
Hi, all.
Any comments?
On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
wrote:
> From: Oleksandr Tyshchenko
>
> The presence of this flag lets us know that the guest domain has statically
> assigned devices which will most likely be used
Hi, all.
Any comments?
On Thu, Aug 3, 2017 at 3:32 PM, Oleksandr Tyshchenko
wrote:
> Hi, Julien
>
> On Thu, Aug 3, 2017 at 2:21 PM, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 25/07/17 18:26, Oleksandr Tyshchenko wrote:
>>>
>>> diff --git
flight 112784 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112784/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2
On Mon, Aug 21, 2017 at 7:31 AM, Peter Zijlstra wrote:
> On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote:
>> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
>
>> > Have you considered a kernel with -mcmodel=small (or medium) instead of
Hi, Julien.
Sorry for the late response.
On Thu, Aug 10, 2017 at 6:13 PM, Julien Grall wrote:
> Hi,
>
> On 10/08/17 15:27, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Aug 8, 2017 at 2:34 PM, Julien Grall wrote:
>>>
>>> On 26/07/17 16:09, Oleksandr
Long pressed key could not show right in XEN vncviewer after tigervnc client
changed the way how to send repeat keys, from "Down Up Down Up ..." to "Down
Down Dow." By enable EV_REP bit here, XEN keyboard device will trigger default
auto repeat process from input subsystem, and make auto repeat
On 08/21/2017 01:07 PM, Jan Beulich wrote:
And remember, this is not "We have tested all compiler versions and
promise you there are no bugs." It's, "If someone finds a bug for this
set of compilers, we will tell you about it so you can do something
about it."
>>>
>>> I can
On Mon, Aug 21, 2017 at 09:14:45AM -0600, Jan Beulich wrote:
> >>> On 21.08.17 at 16:49, wrote:
> > Another option is to (ab)use the msi.gflags field to add another flag
> > in order to signal Xen whether the interrupt should be unmasked. This
> > is in line with what you
>>> On 21.08.17 at 16:49, wrote:
> Another option is to (ab)use the msi.gflags field to add another flag
> in order to signal Xen whether the interrupt should be unmasked. This
> is in line with what you suggest below.
From a brief look it looks like this would be doable,
On 08/21/2017 10:46 AM, Juergen Gross wrote:
> On 21/08/17 16:31, Boris Ostrovsky wrote:
>> On 08/21/2017 09:33 AM, Juergen Gross wrote:
>>> On 06/08/17 18:44, Mikko Rapeli wrote:
Both are needed to compile in userspace. Fixes these
userspace compile errors:
flight 112752 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112752/
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. 112661
On Mon, Aug 21, 2017 at 06:22:05AM -0600, Jan Beulich wrote:
> >>> On 21.08.17 at 11:46, wrote:
> > Xen never detects the MSIX table entry unmask because it happens
> > before the MSIX is bound to the guest, so the Xen msixtbl handlers are
> > not aware of this memory
On 21/08/17 16:31, Boris Ostrovsky wrote:
> On 08/21/2017 09:33 AM, Juergen Gross wrote:
>> On 06/08/17 18:44, Mikko Rapeli wrote:
>>> Both are needed to compile in userspace. Fixes these
>>> userspace compile errors:
>>>
>>> xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
>>>
flight 112749 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515
On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote:
> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote:
> > Have you considered a kernel with -mcmodel=small (or medium) instead of
> > -fpie
> > -mcmodel=large? We can pick a random 2GB window in the (non-kernel)
On 08/21/2017 09:33 AM, Juergen Gross wrote:
> On 06/08/17 18:44, Mikko Rapeli wrote:
>> Both are needed to compile in userspace. Fixes these
>> userspace compile errors:
>>
>> xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
>> grant_ref_t ref;
>> ^
>> xen/gntdev.h:153:4:
On Mon, Aug 21, 2017 at 03:32:22PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 16, 2017 at 05:12:35PM +0200, Ingo Molnar wrote:
> > Unfortunately mcmodel=large looks pretty heavy too AFAICS, at the machine
> > instruction level.
> >
> > Function calls look like this:
> >
> > -mcmodel=medium:
>
On Mon, Aug 21, 2017 at 03:09:12PM +0100, Wei Liu wrote:
> That header file is only used by x86. Merge is into the x86 header.
>
> Signed-off-by: Wei Liu
[...]
> +#define HVM_IRQ_DPCI_MACH_PCI(1 << _HVM_IRQ_DPCI_MACH_PCI_SHIFT)
> +#define HVM_IRQ_DPCI_MACH_MSI
Wei Liu (3):
xen: move hvm save code under common to x86
xen: merge common hvm/irq.h into x86 hvm/irq.h
x86: switch to plain bool in passthrough code
xen/arch/x86/cpu/mcheck/vmce.c | 2 +-
xen/arch/x86/cpu/vpmu_amd.c | 2 +-
xen/arch/x86/hvm/save.c
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/drivers/passthrough/io.c | 16
xen/include/asm-x86/hvm/irq.h | 6 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git
The code is only used by x86 at this point. Merge common/hvm/save.c
into x86 hvm/save.c. Move the headers and fix up inclusions. Remove
the now empty common/hvm directory.
Also fix some issues while moving:
1. removing trailing spaces;
2. fix multi-line comment;
3. make "i" in hvm_save unsigned
That header file is only used by x86. Merge is into the x86 header.
Signed-off-by: Wei Liu
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
When the guest writes to the RTC, Xen emulates it and broadcasts a
TIMEOFFSET ioreq. Emit an RTC_CHANGE QMP message when this happens
rather than ignoring it so that something useful can be done with the
information.
Signed-off-by: Ross Lagerwall
---
On Mon, Aug 21, 2017 at 09:49:01AM -0400, Boris Ostrovsky wrote:
> On 08/21/2017 09:33 AM, Wei Liu wrote:
> > On Mon, Aug 21, 2017 at 09:28:15AM -0400, Boris Ostrovsky wrote:
> >> On 06/19/2017 09:00 AM, Ian Jackson wrote:
> >>> Wei Liu writes ("Re: [PATCH] ipxe: update to newer commit"):
>
>>> On 17.08.17 at 12:30, wrote:
> On 16/08/17 19:33, Boris Ostrovsky wrote:
>> .. so that it's easy to find pages that need to be scrubbed (those pages are
>> now marked with _PGC_need_scrub bit).
>>
>> We keep track of the first unscrubbed page in a page buddy using
On 08/21/2017 09:33 AM, Wei Liu wrote:
> On Mon, Aug 21, 2017 at 09:28:15AM -0400, Boris Ostrovsky wrote:
>> On 06/19/2017 09:00 AM, Ian Jackson wrote:
>>> Wei Liu writes ("Re: [PATCH] ipxe: update to newer commit"):
On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote:
> To get
On Mon, Aug 21, 2017 at 09:28:15AM -0400, Boris Ostrovsky wrote:
> On 06/19/2017 09:00 AM, Ian Jackson wrote:
> > Wei Liu writes ("Re: [PATCH] ipxe: update to newer commit"):
> >> On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote:
> >>> To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to
On Wed, Aug 16, 2017 at 05:12:35PM +0200, Ingo Molnar wrote:
> Unfortunately mcmodel=large looks pretty heavy too AFAICS, at the machine
> instruction level.
>
> Function calls look like this:
>
> -mcmodel=medium:
>
>757: e8 98 ff ff ff callq 6f4
>
> -mcmodel=large
>
>
On 06/08/17 18:44, Mikko Rapeli wrote:
> Both are needed to compile in userspace. Fixes these
> userspace compile errors:
>
> xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
> grant_ref_t ref;
> ^
> xen/gntdev.h:153:4: error: unknown type name ‘domid_t’
> domid_t domid;
>
On 06/19/2017 09:00 AM, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] ipxe: update to newer commit"):
>> On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote:
>>> To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7.
>>>
>>> The only patch we have applies cleanly.
>>>
>>>
On 21/08/17 13:46, Jan Beulich wrote:
On 21.08.17 at 13:55, wrote:
>> This avoids unnecessary updates to the stack shadow copy of cr4 during
>> critical regions with interrupts disabled.
> Hmm, yes - we don't access CR4 in #MC or NMI handling, do we?
#MC and NMI
>>> On 21.08.17 at 13:55, wrote:
> This avoids unnecessary updates to the stack shadow copy of cr4 during
> critical regions with interrupts disabled.
Hmm, yes - we don't access CR4 in #MC or NMI handling, do we?
> No change in behaviour.
>
> Signed-off-by: Andrew
>>> On 21.08.17 at 14:32, wrote:
>> > - Make QEMU setup the vectors when the table entries are unmasked,
>>>even if MSIX is not enabled.
>>> - Provide an hypercall so QEMU can unmask MSIX vectors on behalf of
>>>the guest. This would be used to unmask the entries if MSIX
>>> On 21.08.17 at 12:07, wrote:
> * Completion of the x86 insn emulator (as far as possible)
> - XEN-46
> - Jan Beulich
Patches for the next step have been pending unreviewed for
exactly 2 months. Considering how much review of new
functionality patches by various
- Make QEMU setup the vectors when the table entries are unmasked,
even if MSIX is not enabled.
- Provide an hypercall so QEMU can unmask MSIX vectors on behalf of
the guest. This would be used to unmask the entries if MSIX is
enabled with table entries already unmasked.
Neither
>>> On 21.08.17 at 11:46, wrote:
> Xen never detects the MSIX table entry unmask because it happens
> before the MSIX is bound to the guest, so the Xen msixtbl handlers are
> not aware of this memory region.
>
> The two possible solutions I see to this are:
>
> - Make
>>> On 21.08.17 at 12:59, wrote:
> On Wed, Aug 9, 2017 at 8:36 AM, Jan Beulich wrote:
> On 08.08.17 at 13:16, wrote:
>>> On 08/07/2017 04:59 PM, Jan Beulich wrote:
>>> George Dunlap
flight 112757 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112757/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fa74dd2217aebe6930890e55d58d35e639b18c2e
baseline version:
ovmf
This avoids unnecessary updates to the stack shadow copy of cr4 during
critical regions with interrupts disabled.
No change in behaviour.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/flushtlb.c | 19 +--
1 file
>>> On 21.08.17 at 12:28, wrote:
> Hi Jan,
>
> On 7 August 2017 at 14:44, Jan Beulich wrote:
> Bhupinder Thakur 08/07/17 10:55 AM >>>
>>>@@ -1148,6 +1149,24 @@ struct xen_domctl_psr_cat_op {
>>>uint32_t target;
From: Vivek Kumar Chaubey
Allow setting system enclosure asset tag for HVM guest. Guest OS can
check and perform desired operation like support installation.
Also added documentation of '~/bios-string/*' xenstore keys into
docs/misc/xenstore-paths.markdown
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 21 August 2017 12:02
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
>
> Subject: Re: [PATCH v3 09/52]
branch xen-4.5-testing
xenbranch xen-4.5-testing
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree:
flight 112750 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
112647
On 21/08/17 10:33, Paul Durrant wrote:
>> -Original Message-
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 16 August 2017 13:52
>> To: xen-de...@lists.xenproject.org
>> Cc: Juergen Gross ; Paul Durrant
>> ; Jan Beulich
On Wed, Aug 9, 2017 at 8:36 AM, Jan Beulich wrote:
On 08.08.17 at 13:16, wrote:
>> On 08/07/2017 04:59 PM, Jan Beulich wrote:
>> George Dunlap 08/07/17 12:27 PM >>>
So it seems that people are still not quite
Hi Jan,
On 7 August 2017 at 14:44, Jan Beulich wrote:
Bhupinder Thakur 08/07/17 10:55 AM >>>
>>@@ -1148,6 +1149,24 @@ struct xen_domctl_psr_cat_op {
>>uint32_t target;/* IN */
>>uint64_t data; /* IN/OUT */
>>};
>>+
>>+struct
1 - 100 of 137 matches
Mail list logo