On 06/03/18 08:58, Jan Beulich wrote:
On 06.03.18 at 08:01, wrote:
>> On 05/03/18 17:43, Jan Beulich wrote:
>> On 02.03.18 at 09:13, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -509,6 +509,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
void write_
>>> On 06.03.18 at 06:19, wrote:
> flight 120239 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/120239/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-win7-amd64 7 xen-b
>>> On 06.03.18 at 09:06, wrote:
> On 06/03/18 08:58, Jan Beulich wrote:
> On 06.03.18 at 08:01, wrote:
>>> On 05/03/18 17:43, Jan Beulich wrote:
>>> On 02.03.18 at 09:13, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -509,6 +509,8 @@ void make_cr3(struct vc
>>> 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.
>
> The end result is:
>
>
> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/h
>>> On 02.03.18 at 17:55, wrote:
> Several of the VMs in the Massachusetts Xen Project Test Lab, which
> runs our community osstest instance, need to be upgraded. And we want
> to sort out some oddities with the way the storage is configured.
>
> This will involve a long outage, maybe 3 days or
>>> On 28.02.18 at 17:47, wrote:
> On 28/02/18 13:51, Jan Beulich wrote:
>> 1: remove page.h and processor.h inclusion from asm_defns.h
>> 2: use PDEP for PTE flags insertion when available
>> 3: use PDEP/PEXT for maddr/direct-map-offset conversion when available
>> 4: use PDEP/PEXT for PFN/PDX co
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 console functions
were enclosed into unnecessary #ifdefs CONFIG_X86. Rem
>>> On 06.03.18 at 09:51, 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 console functions
> were enc
On Mon, Mar 05, 2018 at 11:30:35AM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:25 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:42AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
> > > Handle communication with the backend:
> > > - sen
flight 120244 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120244/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat
fail REGR. vs. 119859
Tes
On 03/06/2018 11:26 AM, Daniel Vetter wrote:
On Mon, Mar 05, 2018 at 11:30:35AM +0200, Oleksandr Andrushchenko wrote:
On 03/05/2018 11:25 AM, Daniel Vetter wrote:
On Wed, Feb 21, 2018 at 10:03:42AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Handle communication with
[Moving over to xen-devel, cc'ing a few people]
On Tue, Mar 6, 2018 at 8:16 AM, John Naggets wrote:
> Hi George,
>
> You will find the output of "xl dmesg" below. I also managed to
> reproduce this problem on another test server. That test server is an
> IBM System x3250 M5 server which uses UEFI
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
---
drivers/xen/xenbus/xenbus_probe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/
On 06/03/18 10:04, George Dunlap wrote:
> [Moving over to xen-devel, cc'ing a few people]
>
> On Tue, Mar 6, 2018 at 8:16 AM, John Naggets wrote:
>> Hi George,
>>
>> You will find the output of "xl dmesg" below. I also managed to
>> reproduce this problem on another test server. That test server i
>>> On 06.03.18 at 11:04, wrote:
> On Tue, Mar 6, 2018 at 8:16 AM, John Naggets wrote:
>> You will find the output of "xl dmesg" below. I also managed to
>> reproduce this problem on another test server. That test server is an
>> IBM System x3250 M5 server which uses UEFI. So the hardware is not
>>> On 06.03.18 at 11:19, wrote:
On 06.03.18 at 11:04, wrote:
>> On Tue, Mar 6, 2018 at 8:16 AM, John Naggets
>> wrote:
>>> You will find the output of "xl dmesg" below. I also managed to
>>> reproduce this problem on another test server. That test server is an
>>> IBM System x3250 M5 serv
On Tue, Mar 6, 2018 at 10:15 AM, Andrew Cooper
wrote:
> On 06/03/18 10:04, George Dunlap wrote:
>> [Moving over to xen-devel, cc'ing a few people]
>>
>> On Tue, Mar 6, 2018 at 8:16 AM, John Naggets
>> wrote:
>>> Hi George,
>>>
>>> You will find the output of "xl dmesg" below. I also managed to
>
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 Jaggi
Merge few more changes from linux
On Tue, Mar 6, 2018 at 11:15 AM, Andrew Cooper
wrote:
> Upgrade Grub to 2.02.
>
> The problem here is that Grub is starting EFI, but doesn't pass the EFI
> details to Xen, and Xen therefore cannot locate the RSDP.
I think my Ubuntu 17.10 system is already using GRUB 2.02, at least
this is how it
>>> On 06.03.18 at 11:24, wrote:
> On Tue, Mar 6, 2018 at 11:15 AM, Andrew Cooper
> wrote:
>> Alternatively, switch back to legacy boot, at which point it will all
>> start working again.
>
> This is unfortunately not possible. This is a new server which does
> not offer legacy boot any more, it
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.
> >
> > The end result is:
> >
> >
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 new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to ad
Hi Stefano,
On 02/03/18 19:06, Stefano Stabellini wrote:
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index d948250..ce18f0c 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -134,7 +134,7 @@
/* Architectural minimum cacheline size is 4 32-bit
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
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
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
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
__
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 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
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 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 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 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
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
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
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
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 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 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
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 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
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 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
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 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 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
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 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
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
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 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
>>> 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 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 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 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 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 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
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 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 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
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:
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
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
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 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
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 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
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 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
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
> >>
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
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:
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
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,
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
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 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
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
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,
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
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 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 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,
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 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 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
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:
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
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:
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
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 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
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
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,
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 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 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
1 - 100 of 123 matches
Mail list logo
