>>> On 06.03.18 at 20:24, wrote:
> On Tue, 6 Mar 2018, Jan Beulich wrote:
>> these stable releases should go out before the end of the month.
>> Please point out backport candidates you find missing from the
>> respective staging branches, but which you consider relevant.
>> Please note that 4.7.5
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Saturday, March 3, 2018 12:19 AM
>
> Commit 406817 doesn't update nested VMX code in order to take into
> account L1 CR4 host mask when nested guest (L2) writes to CR4, and
> thus the mask written to CR4_GUEST_HOST_MASK is likely not as
flight 120260 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120260/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120047
test-amd64-amd64-xl-qemut-win7-amd64 17
On Tue, 6 Mar 2018, Stefano Stabellini wrote:
> On Wed, 31 Jan 2018, Julien Grall wrote:
> > When working on getting Xen booting on rochester{0,1} (Thunder-X in
> > Osstest),
> > I blacklist them with this small patch. I will clean-up it and send it on
> > the ML:
> >
> > diff --git a/xen/arch/a
flight 120257 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120257/
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 120288 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120288/
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
flight 120256 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 10 debian-install fail REGR. vs. 120140
test-armhf-armhf-lib
Using libc functions in the middle of emulation may corrupt FPU state. Save
and restore FPU state around the progress marker which is the only current
libc function on the success path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
tools/tests/x86_emulator/test_x86_emulator.c | 5 +
Currently with then native toolchain on Debian Jessie ./test_x86_emulator
yeilds:
Testing AVX2 256bit single native execution...okay
Testing AVX2 256bit single 64-bit code sequence...[line 933] failed!
The bug is that libc's memcpy() in read() uses %xmm8 (specifically, in
__memcpy_sse2_unalig
Introduce common helpers for saving and restoring FPU state. During
emul_test_init(), calculate whether to use xsave or fxsave, and tweak the
existing mxcsr_mask logic to avoid using another large static buffer.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
tools/tests/x86_emulator/x86-
* Align the function call names, which aligns all subsequent data on the
line.
* Convert x86_segment and X86EMUL_ constants to strings rather than printing
raw numbers.
* Move the printing to the end of the function, and either hexdump the result
or print the failure code.
No change by
The main bugfix is in patch 2. Patch 3 is some extra debugging developed
while investigating the issue.
Andrew Cooper (3):
tests/x86emul: Helpers to save and restore FPU state
tests/x86emul: Save and restore FPU state in the emulator callbacks
tests/x86emul: Improve the utility of verbose m
All uploaded PM data from offline CPUs takes the info from vCPU 0 and
changing only the acpi_id. For processors which P-state coordination type
is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
(_PSD), because Xen will ignore cpufreq domains existence.
Albeit for hardware ex
On Tue, 6 Mar 2018, Julien Grall wrote:
> Hi Stefano,
>
> Something is wrong with your threading again. Patch #2-7 have "In-Reply-To"
> matching patch #1 and not the cover letter.
Thanks, I lost my git configuration.
> On 02/03/18 19:06, Stefano Stabellini wrote:
> > Even different cpus in big.
Jan Beulich writes ("Re: osstest planned outage consultation"):
> The most recent flights don't look too bad anymore (at least
> most of the have started disappearing again), so
> there's some hop for pushes soon. I hope to get around to
> push another batch of backports today, in particular to ge
On Tue, 6 Mar 2018, Jan Beulich wrote:
> All,
>
> these stable releases should go out before the end of the month.
> Please point out backport candidates you find missing from the
> respective staging branches, but which you consider relevant.
> Please note that 4.7.5 is expected to be the last xe
On Fri, Mar 02, 2018 at 02:29:29PM -0800, Maran Wilson wrote:
> On 3/2/2018 1:20 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:
> >>The start info structure that is defined as part of the x86/HVM direct boot
> >>ABI and used for starting Xen PVH gu
flight 120253 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120253/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
120037
Tests whic
On Tue, Mar 06, 2018 at 06:18:12PM +, George Dunlap wrote:
> On 03/06/2018 06:08 PM, Wei Liu wrote:
> > On Tue, Mar 06, 2018 at 05:08:43PM +, George Dunlap wrote:
> >> We don't promise to protect you against rogue stub domain binaries;
> >> only from the running domain once the guest has co
On 03/02/2018 09:39 AM, Lars Kurth wrote:
Hi all,
(sorry for the extensive distribution list - I went through MAINTAINERS and
people who may have an interest)
I would like to start organizing a recurring x86 community call to discuss and
sync-up on upcoming features for Xen on x86. This call w
George Dunlap writes ("[PATCH] SUPPORT.md: Clarify stubdomain support"):
> We don't promise to protect you against rogue stub domain binaries;
> only from the running domain once the guest has come up.
Acked-by: Ian Jackson
___
Xen-devel mailing list
X
On 03/06/2018 06:08 PM, Wei Liu wrote:
> On Tue, Mar 06, 2018 at 05:08:43PM +, George Dunlap wrote:
>> We don't promise to protect you against rogue stub domain binaries;
>> only from the running domain once the guest has come up.
>>
>> Signed-off-by: George Dunlap
>> ---
>> CC: Ian Jackson
>
flight 120286 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120286/
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
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a given IRQ
number and (in case of private interrupts) the right VCPU.
This also includes the correspond
On Tue, Mar 06, 2018 at 05:08:43PM +, George Dunlap wrote:
> We don't promise to protect you against rogue stub domain binaries;
> only from the running domain once the guest has come up.
>
> Signed-off-by: George Dunlap
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Andrew Cooper
> CC: Jan B
Hi,
On 06/03/18 17:46, Julien Grall wrote:
> Hi Andre,
>
> On 05/03/18 16:03, Andre Przywara wrote:
>> Add a new header file for the new and improved GIC implementation.
>> The big change is that we now have a struct vgic_irq per IRQ instead
>> of spreading all the information over various bitmap
On Tue, Mar 06, 2018 at 09:14:50AM -0700, Jan Beulich wrote:
> >>> On 06.03.18 at 11:56, wrote:
> > Wei Liu writes ("Merging 4.10.0-shim-comet-3 tag into staging-4.10"):
> >> Please check if the shape and form of this branch is OK. And please
> >> indicate if anything is missing.
> >
> > The bran
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
Add a new header file for the new and improved GIC implementation.
The big change is that we now have a struct vgic_irq per IRQ instead
of spreading all the information over various bitmaps in the ranks.
We include this new header conditionally
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The emulated ARM SBSA UART is using level triggered IRQ semantics,
however the current VGIC can only handle edge triggered IRQs, really.
Disable the existing workaround for this problem in case we have the
new VGIC in place, which can properly h
On 06/03/18 17:15, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
/*
* Arch timer interrupt really ought to be level triggered, since the
* design of the timer/comparator mechanism is based around that
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7411bff7a
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we have to sync the state of the interrupt condition at certain
points to catch when the line go
We don't promise to protect you against rogue stub domain binaries;
only from the running domain once the guest has come up.
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
CC: Stefano Stabellini
CC: Konrad Wilk
CC: Julien Grall
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
I
From: David E. Box
Gemini Lake uses the same C-states as Broxton and also uses the
IRTL MSR's to determine maximum C-state latency.
Signed-off-by: David E. Box
Acked-by: Len Brown
Signed-off-by: Rafael J. Wysocki
[Linux commit 1b2e87687d3f951a66900cab6f1583d94099d2f7]
Signed-off-by: Jan Beuli
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_pendi
On Tue, 06 Mar 2018 17:04:41 +0100,
Oleksandr Andrushchenko wrote:
>
> If we decide to negotiate the parameters, then it can't be done
> at .open stage as well, as at this moment we don't know stream
> parameters yet, e.g. we don't know the number of channels, PCM
> format etc.
Hi,
On 06/03/18 15:58, Andre Przywara wrote:
Hi,
On 06/03/18 15:46, Julien Grall wrote:
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The bit definition for the CPUID mask in the GICv2 LR register was
wrong, fortunately the current implementation does not use that bit.
Fix it up (it's s
>>> On 06.03.18 at 11:56, wrote:
> Wei Liu writes ("Merging 4.10.0-shim-comet-3 tag into staging-4.10"):
>> Please check if the shape and form of this branch is OK. And please
>> indicate if anything is missing.
>
> The branch shape looks good to me.
Same here - feel free to push to the actual s
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
So far our LR read/write functions do not handle the EOI bit and the
source CPUID bits in an LR, because the current VGIC implementation does
not use them.
Extend the gic_lr data structure to hold these bits of information as
well, packing it on
On 03/06/2018 05:06 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 15:48:53 +0100,
Oleksandr Andrushchenko wrote:
And, now an open question for XEN comes: what kind of restriction
should be applied to the frontend. Obviously it depends on the
backend, so there must be some communication, and the r
Hi,
On 06/03/18 15:46, Julien Grall wrote:
> Hi Andre,
>
> On 05/03/18 16:03, Andre Przywara wrote:
>> The bit definition for the CPUID mask in the GICv2 LR register was
>> wrong, fortunately the current implementation does not use that bit.
>> Fix it up (it's starting at bit 10, not bit 9) and c
Roger Pau Monné writes ("Re: [PATCH] libxl/pvh: force PVH guests to use the
xenstore shutdown"):
> On Tue, Dec 19, 2017 at 02:48:47PM +, Ian Jackson wrote:
> > I think this is a candidate for backporting as far as 4.9 ?
>
> Yes, 4.10 only though (that's when the PVH guest type was introduced)
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The bit definition for the CPUID mask in the GICv2 LR register was
wrong, fortunately the current implementation does not use that bit.
Fix it up (it's starting at bit 10, not bit 9) and clean up some
nearby definitions on the way.
This will be
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
A GICv3 hardware implementation can be implemented in several parts that
communicate with each other (think multi-socket systems).
To make sure that critical settings have arrived at all endpoints, some
bits are tracked using the RWP bit in the
All,
these stable releases should go out before the end of the month.
Please point out backport candidates you find missing from the
respective staging branches, but which you consider relevant.
Please note that 4.7.5 is expected to be the last xenproject.org
managed release from its branch.
Jan
Hi,
On 06/03/18 15:23, Julien Grall wrote:
Hi,
On 05/03/18 16:03, Andre Przywara wrote:
The GICv2 uses bitmaps spanning several MMIO registers for holding some
interrupt state. Similar to GICv3, add a poke helper functions to set
a bit
for a given irq_desc in one of those bitmaps.
At the mom
Hi,
On 05/03/18 16:03, Andre Przywara wrote:
The GICv2 uses bitmaps spanning several MMIO registers for holding some
interrupt state. Similar to GICv3, add a poke helper functions to set a bit
for a given irq_desc in one of those bitmaps.
At the moment there is only one use in gic-v2.c, but ther
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
If we change something in a vCPU that affects its runnability or
otherwise needs the vCPU's attention, we might need to tell the scheduler
about it.
We are using this in one place (vIRQ injection) at the moment, but will
need this at more places
flight 120254 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120254/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 20203d3f98d671d7d7d78f33bbb02cf1d1b3cabe
baseline version:
ovmf b77e1a240e0aa222b2498
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
On a GICv3 in non-compat mode the hypervisor interface is always
accessed via system registers. Those register names have a "ICH_" prefix
in the manual, to differentiate them from the MMIO registers. Also those
registers are mostly 64-bit (compa
On Tue, 06 Mar 2018 15:48:53 +0100,
Oleksandr Andrushchenko wrote:
>
> > And, now an open question for XEN comes: what kind of restriction
> > should be applied to the frontend. Obviously it depends on the
> > backend, so there must be some communication, and the restriction must
> >>
On 03/06/2018 04:27 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 15:13:13 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 03:48 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 14:30:05 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 02:52 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 13:05:1
flight 120250 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120250/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub broken in 120178
test-amd64-i386-migrupgrade
On 06/03/18 10:27, Manish Jaggi wrote:
On 01/19/2018 12:21 AM, Julien Grall wrote:
Hi Manish,
Please use scripts/get_maintainers.pl to CC relevant maintainers. I
have done it for you this time.
Title: s/spacific/specific/
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish
On Tue, 06 Mar 2018 15:13:13 +0100,
Oleksandr Andrushchenko wrote:
>
> On 03/06/2018 03:48 PM, Takashi Iwai wrote:
> > On Tue, 06 Mar 2018 14:30:05 +0100,
> > Oleksandr Andrushchenko wrote:
> >> On 03/06/2018 02:52 PM, Takashi Iwai wrote:
> >>> On Tue, 06 Mar 2018 13:05:16 +0100,
> >>> Oleksandr A
On 06/03/18 13:44, Manish Jaggi wrote:
Hi Julien,
On 01/19/2018 12:21 AM, Julien Grall wrote:
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8efd..f78482ca0c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -6,6 +6,8 @@
e
flight 120282 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120282/
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
On 03/06/2018 03:48 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 14:30:05 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 02:52 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 13:05:16 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 01:32 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 12:25:0
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
The new VGIC will shortly use more bits of the various GIC registers, so
add the respective definitions from the manual.
This series does not seem to use any of the new value you added. Did I
miss anything?
Note that I am not against this pat
Juergen Gross writes ("Re: [Xen-devel] [PATCH v2] tools/xenstore: try to get
minimum thread stack size for watch thread"):
> On 06/03/18 12:24, Olaf Hering wrote:
> > +ifeq ($(CONFIG_Linux),y)
> > +LDLIBS_libxenstore += -ldl
> > +endif
>
> So we need to add this to xenstore.pc, right?
Yes.
Ian.
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
So far the number of list registers (LRs) a GIC implements is only
needed in the hardware facing side of the VGIC code (gic-vgic.c).
The new VGIC will need this information in more and multiple places, so
export a function that returns the numbe
On Tue, 06 Mar 2018 14:30:05 +0100,
Oleksandr Andrushchenko wrote:
>
> On 03/06/2018 02:52 PM, Takashi Iwai wrote:
> > On Tue, 06 Mar 2018 13:05:16 +0100,
> > Oleksandr Andrushchenko wrote:
> >> On 03/06/2018 01:32 PM, Takashi Iwai wrote:
> >>> On Tue, 06 Mar 2018 12:25:07 +0100,
> >>> Oleksandr A
On 05/03/18 17:08, Julien Grall wrote:
On 05/03/18 16:03, Andre Przywara wrote:
Instead of hard coding the architected redistributor stride into the
code, lets use a clear #define to the two values for GICv3 and GICv4 and
clarify the algorithm to determine the needed stride value.
Signed-off-
Hi Julien,
On 01/19/2018 12:21 AM, Julien Grall wrote:
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8efd..f78482ca0c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -6,6 +6,8 @@
enum device_type
{
DEV_DT,
+ DEV
Hi Julien,
On 01/19/2018 12:21 AM, Julien Grall wrote:
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8efd..f78482ca0c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -6,6 +6,8 @@
enum device_type
{
DEV_DT,
+ DEV
>>> On 06.03.18 at 12:28, wrote:
> On 28/02/18 13:00, Jan Beulich wrote:
>> --- unstable.orig/tools/tests/x86_emulator/Makefile
>> +++ unstable/tools/tests/x86_emulator/Makefile
>> @@ -91,7 +91,7 @@ $(addsuffix .h,$(TESTCASES)): %.h: %.c t
>> $(MAKE) -f testcase.mk TESTCASE=$* XEN_TAR
On 03/06/2018 02:52 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 13:05:16 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 01:32 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 12:25:07 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 12:52 PM, Takashi Iwai wrote:
On Mon, 05 Feb 2018 09:24:5
On Tue, 06 Mar 2018 13:05:16 +0100,
Oleksandr Andrushchenko wrote:
>
> On 03/06/2018 01:32 PM, Takashi Iwai wrote:
> > On Tue, 06 Mar 2018 12:25:07 +0100,
> > Oleksandr Andrushchenko wrote:
> >> On 03/06/2018 12:52 PM, Takashi Iwai wrote:
> >>> On Mon, 05 Feb 2018 09:24:58 +0100,
> >>> Oleksandr A
On Mon, 5 Mar 2018 08:27:10 -0300
Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
>
> Patch generated using:
>
> $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
>
> and modified manually.
>
> Signed-off-by: Philippe Mathieu-Daudé
My apolog
On 06/03/18 12:24, Olaf Hering wrote:
> On Fri, Mar 02, Wei Liu wrote:
>
>> But still, Juergen must have tested the change, so I wonder why it
>> doesn't work in your setup. What is your build environment? Gcc version?
>
> Unclear what the difference is between building in clean chroot and locall
>>> On 06.03.18 at 12:07, wrote:
> On 06/03/18 10:41, Olaf Hering wrote:
>> With this option the host admin can decide how a domU should behave when
>> it is migrated across systems of the same class. Since there is always
>> some jitter when Xen calibrates the cpu_khz value, all hosts of the same
>>> On 06.03.18 at 12:50, wrote:
> Regarding the second method of having UEFI loading directly the Xen
> EFI, I tried this out yesterday using the instructions on the Xen wiki
> (https://wiki.xenproject.org/wiki/Xen_EFI#Xen_as_EFI_binary_.28loading.29)
> but I get the following error message right
Am Tue, 6 Mar 2018 11:07:54 +
schrieb Andrew Cooper :
> We should see about using better sources of information. For one, many
> Intel systems actually expose the TSC frequency in the bottom of the
> PLATFORM_INFO MSR, although this isn't architectural, and has been
> replaced with CPUID info
On 03/06/2018 01:32 PM, Takashi Iwai wrote:
On Tue, 06 Mar 2018 12:25:07 +0100,
Oleksandr Andrushchenko wrote:
On 03/06/2018 12:52 PM, Takashi Iwai wrote:
On Mon, 05 Feb 2018 09:24:58 +0100,
Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
Foreword
This change
Hi Andre,
On 05/03/18 16:03, Andre Przywara wrote:
Currently we describe the VGIC specific fields in a structure
*embedded* in struct arch_domain and struct arch_vcpu. These members
there are however related to the current VGIC implementation, and will
be substantially different in the future.
T
Hi,
On 05/03/18 16:03, Andre Przywara wrote:
At the moment vgic_vcpu_inject_irq() is the interface for Xen internal
code and virtual devices to inject IRQs into a guest. This interface has
two shortcomings:
1) It requires a VCPU pointer, which we may not know (and don't need!)
for shared interru
Hi Julien,
On 03/06/2018 12:37 PM, Julien Grall wrote:
> On 06/03/18 11:06, Sergej Proskurin wrote:
>> Hi Julien,
>
> Hi Sergej,
>
>>
>> On 02/28/2018 04:25 PM, Julien Grall wrote:
>>> Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
>>> assumed the read-write lock can be taken
On Tue, Mar 6, 2018 at 11:39 AM, Jan Beulich wrote:
> As indicated in another reply, try using GrUB's "chainloader"
> directive or boot xen.efi directly from the EFI shell or the EFI
> boot loader.
Sorry for my naive question but how do I chainload Xen with GRUB? I
did not find any documentation
Hi,
On 05/03/18 16:03, Andre Przywara wrote:
gic_event_needs_delivery() is not named very intuitively, especially
the gic_ prefix is somewhat misleading.
Rename it to vgic_pending_irq(), which makes it clear that this relates
to the virtual GIC and is about interrupts.
Signed-off-by: Andre Przy
On Mon, Mar 05, 2018 at 07:44:49PM +, Wei Liu wrote:
> Building that branch seems to produce the expected binaries. I will do
> some smoke tests tomorrow to make sure I haven't screwed things up.
Travis build result is positive for both x86 and ARM (although ARM tools
aren't built yet).
Teste
On Tue, Mar 06, 2018 at 12:16:08PM +0800, Haozhong Zhang wrote:
> On 03/02/18 12:03 +, Anthony PERARD wrote:
> > On Wed, Feb 28, 2018 at 05:36:59PM +0800, Haozhong Zhang wrote:
> > > On 02/27/18 17:22 +, Anthony PERARD wrote:
> > > > On Thu, Dec 07, 2017 at 06:18:02PM +0800, Haozhong Zhang
On 06/03/18 11:06, Sergej Proskurin wrote:
Hi Julien,
Hi Sergej,
On 02/28/2018 04:25 PM, Julien Grall wrote:
Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
assumed the read-write lock can be taken recursively. However, this
assumption is wrong and will lead to deadlock w
Am Tue, 6 Mar 2018 11:07:54 +
schrieb Andrew Cooper :
> > One option to avoid the TSC option is to run domUs with tsc_mode=native.
> > This has the drawback that migrating a domU from a "2.3GHz" class host
> > to a "2.4GHz" class host may change the rate at wich the TSC counter
> > increases,
On Tue, 06 Mar 2018 12:25:07 +0100,
Oleksandr Andrushchenko wrote:
>
> On 03/06/2018 12:52 PM, Takashi Iwai wrote:
> > On Mon, 05 Feb 2018 09:24:58 +0100,
> > Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> Hi, all!
> >>
> >> Foreword
> >>
> >>
> >> This chang
On 28/02/18 13:00, Jan Beulich wrote:
> This allows the section contents to be disassembled without going
> through any extra hoops, simplifying the analysis of problems in test
> and/or emulation code.
>
> The blobs being emitted as (r/o) data means we need to accept an
> assembler warning here (a
On 03/06/2018 12:52 PM, Takashi Iwai wrote:
On Mon, 05 Feb 2018 09:24:58 +0100,
Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
Foreword
This change is aimed to add support for explicit back and front
synchronization during playback and capture in response to c
On Fri, Mar 02, Wei Liu wrote:
> But still, Juergen must have tested the change, so I wonder why it
> doesn't work in your setup. What is your build environment? Gcc version?
Unclear what the difference is between building in clean chroot and locally.
This change fixes it for me:
--- a/tools/Rul
Am Tue, 6 Mar 2018 11:07:54 +
schrieb Andrew Cooper :
> This looks like it should be part of the set_tsc_info hypercall, not a
> separate hypercall.
How would one adjust the value at runtime with set_tsc_info of a running domU?
It seems to me set_tsc_info does way more than just applying some
Hi Stefano,
On 02/03/18 23:42, Stefano Stabellini wrote:
On Wed, 28 Feb 2018, Julien Grall wrote:
Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
assumed the read-write lock can be taken recursively. However, this
assumption is wrong and will lead to deadlock when the lock is
On 05/03/18 17:18, Wei Liu wrote:
On Mon, Mar 05, 2018 at 04:39:09PM +, Julien Grall wrote:
(+ tools maintainers)
Hi Andre,
Please don't forget to CC the relevant maintainers.
On 05/03/18 16:03, Andre Przywara wrote:
When creating a GICv3 devicetree node, we currently insert the
redist
>>> On 06.03.18 at 11:41, wrote:
> On Tue, Mar 06, 2018 at 01:21:52AM -0700, Jan Beulich wrote:
>> >>> On 05.03.18 at 20:44, wrote:
>> > I merged 4.10.0-shim-comet-3 tag into staging-4.10, went through all
>> > commits since then and cherry-picked relevant patches from master to
>> > staging-4.10
>>> On 06.03.18 at 12:01, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.9-testing test] 120239:
> regressions -
> FAIL"):
>> (other than
>> adding "async-show-all", as already suggested in the reply to that
>> other flight report).
>
> Thanks for the reminder. I'm about to push the patc
On Tue, Mar 06, 2018 at 08:51:56AM +, Sergey Dyasli wrote:
> The header for PV console contains empty function definitions in case of
> !CONFIG_XEN_GUEST specially to avoid #ifdefs in a code that uses them
> to make the code look cleaner.
>
> Unfortunately, during the release of shim-comet, PV
On 06/03/18 10:41, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.
>
> Add a n
Hi Julien,
On 02/28/2018 04:25 PM, Julien Grall wrote:
> Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
> assumed the read-write lock can be taken recursively. However, this
> assumption is wrong and will lead to deadlock when the lock is
> contended.
>
> To avoid the nested l
Jan Beulich writes ("Re: [Xen-devel] [xen-4.9-testing test] 120239: regressions
- FAIL"):
> (other than
> adding "async-show-all", as already suggested in the reply to that
> other flight report).
Thanks for the reminder. I'm about to push the patch below.
I looked at the docs for async-show-al
On 06/03/18 11:10, Arvind Yadav wrote:
> Never directly free @dev after calling device_register(), even
> if it returned an error! Always use put_device() to give up the
> reference initialized.
>
> Signed-off-by: Arvind Yadav
Reviewed-by: Juergen Gross
Juergen
__
Hi Stefano,
Something is wrong with your threading again. Patch #2-7 have
"In-Reply-To" matching patch #1 and not the cover letter.
On 02/03/18 19:06, Stefano Stabellini wrote:
Even different cpus in big.LITTLE systems are expected to have the same
dcache line size. Unless the minimum of all
Wei Liu writes ("Merging 4.10.0-shim-comet-3 tag into staging-4.10"):
> Please check if the shape and form of this branch is OK. And please
> indicate if anything is missing.
The branch shape looks good to me.
> Building that branch seems to produce the expected binaries. I will do
> some smoke t
On Mon, 05 Feb 2018 09:24:58 +0100,
Oleksandr Andrushchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> Hi, all!
>
> Foreword
>
>
> This change is aimed to add support for explicit back and front
> synchronization during playback and capture in response to comments
> raised during up
1 - 100 of 123 matches
Mail list logo
