Hi Konrad,
On 1/17/19 11:29 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 15, 2019 at 09:20:36AM +0100, Roger Pau Monné wrote:
>> On Tue, Jan 15, 2019 at 12:41:44AM +0800, Dongli Zhang wrote:
>>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>>> therefore should be re
>>> On 15.02.19 at 19:20, wrote:
> On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
>> >>> On 15.02.19 at 05:23, wrote:
>> > The MCE/EDAC support code appears to be in rather poor shape.
>> >
>> > The AMD code mentions Family 10h, which might have been available 10
>> > years ago. T
On Mon, Feb 18, 2019 at 01:12:16AM -0700, Jan Beulich wrote:
> >>> On 15.02.19 at 19:20, wrote:
> > On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> >> Well, Fam10 is mentioned explicitly, but as per the use of e.g.
> >> mcheck_amd_famXX newer ones are supported by this code
> >> as
Extend the framework to support (simple) monitor related tests.
Changes from v2
- Check the returned value from xc_translate_foreign_address.
Changes from v1:
- Refactored the monitor test (cleanup)
- Replace the "emul-unimplemented" test with a simpler mem_access test
Petre Pircalabu (4):
xtf
The monitor application resets the execute permisions on a specific page
of the DOMU and handles the generated vm_event request.
Signed-off-by: Petre Pircalabu
---
docs/all-tests.dox | 1 +
tests/monitor-mem-access/Makefile | 14
tests/monitor-mem-access/main.c| 37
This class starts alongside the domain a monitor application which opens
an event channel corresponding to that domain and handles the received
requests.
Use the "monitor_args" key to pass test specific arguments to the
monitor application.
The arguments will be added in the test's Makefile using t
The Executable test class runs on host (dom0). The class spawns a
process and searches the program output(stdio) for a specific pattern.
Signed-off-by: Petre Pircalabu
---
xtf/__init__.py| 2 +-
xtf/executable_test.py | 83 ++
xtf/suite.py
Split the xtf-runner script file into multiple modules in order to
support multiple test types.
Features:
- 2 abstract types (TestInfo and TestInstance) to represent the
test information (info.json) and, respectively to implement the test
execution.
TestInfo has to implement the "all_ins
>>> On 18.02.19 at 09:42, wrote:
> On Mon, Feb 18, 2019 at 01:12:16AM -0700, Jan Beulich wrote:
>> >>> On 15.02.19 at 19:20, wrote:
>> > On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
>> >> Well, Fam10 is mentioned explicitly, but as per the use of e.g.
>> >> mcheck_amd_famXX newer
Commit 0bc6a68da5 "xen/arm: Replace call_smc with arm_smccc_smc"
mistakenly forgot to populate arm_smccc_res. So a garbagge value was
used as return value.
Coverity-ID: 1476827
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
The 3rd argument of function dt_property_read_u32() is only valid when
the call succeeded. So we cannot assume the value will not be modifed
in case of failure.
The documentation of Dom0less does not give a default value when the
property "cpus" is not set. So require the property in the configura
On 18/02/2019 10:03, Julien Grall wrote:
> The 3rd argument of function dt_property_read_u32() is only valid when
> the call succeeded. So we cannot assume the value will not be modifed
> in case of failure.
>
> The documentation of Dom0less does not give a default value when the
> property "cpus"
Hi Andrew,
On 18/02/2019 10:06, Andrew Cooper wrote:
On 18/02/2019 10:03, Julien Grall wrote:
The 3rd argument of function dt_property_read_u32() is only valid when
the call succeeded. So we cannot assume the value will not be modifed
in case of failure.
The documentation of Dom0less does not
The 3rd argument of function dt_property_read_u32() is only valid when
the call succeeded. So we cannot assume the value will not be modifed
in case of failure.
The documentation of Dom0less does not give a default value when the
property "cpus" is not set. So require the property in the configura
Since commit 25eb5eec79 "xen: Fix inconsistent callers of panic()" all
the panic message should end with a newline. Unfortunately, some
commits pushed afterwards does not follow the rule.
Modify the offending panic messages to avoid more inconsistency.
Signed-off-by: Julien Grall
---
Cc: andre
On 18/02/2019 10:21, Julien Grall wrote:
> Since commit 25eb5eec79 "xen: Fix inconsistent callers of panic()" all
> the panic message should end with a newline. Unfortunately, some
> commits pushed afterwards does not follow the rule.
>
> Modify the offending panic messages to avoid more inconsiste
flight 133282 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133282/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132820
test-armhf-armhf-libvirt 14 save
On Fri, Feb 15, 2019 at 06:48:25PM +0100, George Dunlap wrote:
>
> > On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
> >
> > This is in preparation for also changing p2m_entry_modify to return an
> > error code.
> >
> > No functional change intended.
>
> I think you need to explain wheny/w
On Fri, Feb 15, 2019 at 07:15:53PM +0100, George Dunlap wrote:
>
>
> > On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
> >
> > So that the specific handling can be removed from
> > atomic_write_ept_entry and be shared with npt and shadow code.
> >
> > This commit also removes the check tha
>>> On 15.02.19 at 18:48, wrote:
>> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
>> @@ -321,7 +321,7 @@ static int p2m_pt_set_recalc_range(struct p2m_domain
>> *p2m,
>> if ( (l1e_get_flags(e) & _PAGE_PRESENT) && !needs_recalc(l1, e) )
>> {
>> set_re
On Fri, Feb 15, 2019 at 11:08:41AM -0800, Stefano Stabellini wrote:
[...]
> >
> > Not sure how Stefano got the 157k number. Here are some results from
> > staging.
>
> See my attached .config
I see. So these are non-debug builds. I have rerun with your config.
* HVM only -- Stefano's config
cl
On Fri, Feb 15, 2019 at 03:18:33PM +0100, Roger Pau Monne wrote:
> There have been several reports of the dom0 builder running out of
> memory when building a PVH dom0 without having specified a dom0_mem
> value. Print a warning message if dom0_mem is not set when booting in
> PVH mode.
>
> This i
>>> On 15.02.19 at 16:41, wrote:
> domain_pause_except_self() was introduced to allow a domain to pause
> itself while doing altp2m operations. However, as written, it has a
> risk fo deadlock if two vcpus enter the loop at the same time.
>
> Luckily, there's already a solution for this: Attempt
Thank you Wei. It's interesting though that the full vs HVM only is almost
identical in terms of SLOC's
Lars
> On 18 Feb 2019, at 11:12, Wei Liu wrote:
>
> On Fri, Feb 15, 2019 at 11:08:41AM -0800, Stefano Stabellini wrote:
> [...]
>>>
>>> Not sure how Stefano got the 157k number. Here are som
>>> On 15.02.19 at 16:41, wrote:
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
>
> This can lead to domain crashes in the vmx_vmexit_handler() code
>
On 2/18/19 1:19 PM, Jan Beulich wrote:
On 15.02.19 at 16:41, wrote:
HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
on purpose (as it was originally supposed to cater to a in-guest
agent, and a domain pausing itself is not a good idea).
This can lead to domain crashes in the
On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
> Thank you Wei. It's interesting though that the full vs HVM only is almost
> identical in terms of SLOC's
> Lars
The cloc target counts the files in the dependency graph generated by
make. A lot of the files contain both common x86 cod
On 2/18/19 11:23 AM, Wei Liu wrote:
> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
>> Thank you Wei. It's interesting though that the full vs HVM only is almost
>> identical in terms of SLOC's
>> Lars
>
> The cloc target counts the files in the dependency graph generated by
> make.
On 18/02/2019 10:42, Julien Grall wrote:
> Commit 0bc6a68da5 "xen/arm: Replace call_smc with arm_smccc_smc"
> mistakenly forgot to populate arm_smccc_res. So a garbagge value was
> used as return value.
>
> Coverity-ID: 1476827
> Signed-off-by: Julien Grall
Release-acked-by: Juergen Gross
Jue
On 18/02/2019 11:14, Julien Grall wrote:
> The 3rd argument of function dt_property_read_u32() is only valid when
> the call succeeded. So we cannot assume the value will not be modifed
> in case of failure.
>
> The documentation of Dom0less does not give a default value when the
> property "cpus"
On 18/02/2019 11:21, Julien Grall wrote:
> Since commit 25eb5eec79 "xen: Fix inconsistent callers of panic()" all
> the panic message should end with a newline. Unfortunately, some
> commits pushed afterwards does not follow the rule.
>
> Modify the offending panic messages to avoid more inconsist
On 15/02/2019 15:18, Roger Pau Monne wrote:
> There have been several reports of the dom0 builder running out of
> memory when building a PVH dom0 without having specified a dom0_mem
> value. Print a warning message if dom0_mem is not set when booting in
> PVH mode.
>
> This is a temporary workaro
Hi all,
Arm never supported an M2P yet there are some helpers implemented to deal with
the common code. However, the implementation of mfn_to_gmfn is completely
bogus.
This series aims to properly disable the M2P on Arm. See patch #8 for the
rationale regarding the lack of M2P on Arm.
While look
No functional changes.
Signed-off-by: Julien Grall
---
xen/arch/x86/tboot.c | 2 +-
xen/common/page_alloc.c | 2 +-
xen/include/asm-arm/mm.h | 4 ++--
xen/include/asm-x86/mm.h | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.
The parameter "d" holds the domain and is not modified by the function.
So constify it.
Signed-off-by: Julien Grall
---
xen/include/asm-x86/p2m.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 2095076556..b6852dc133
mfn_to_gfn and mfn_to_gmfn are doing exactly the same except the former
is using mfn_t.
Furthermore, the naming of the former is more consistent with the
current naming scheme (GFN/MFN). So use replace mfn_to_gmfn with
mfn_to_gfn in x86 code.
No functional changes.
Signed-off-by: Julien Grall
-
mfn_to_pdx adds more safety than pfn_to_pdx. Replace all but on place in
the Arm code to use the former.
No functional changes.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c| 2 +-
xen/include/asm-arm/mm.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xe
No functional changes.
Signed-off-by: Julien Grall
---
xen/arch/x86/mm.c | 9 +
xen/arch/x86/mm/p2m.c | 2 +-
xen/arch/x86/mm/shadow/multi.c | 2 +-
xen/common/page_alloc.c| 4 ++--
xen/include/asm-arm/mm.h | 8
xen/include/asm-x86/mm.h
Convert online_page, offline_page and query_page_offline to use
typesafe MFN.
No functional changes.
Signed-off-by: Julien Grall
---
xen/arch/x86/cpu/mcheck/mcaction.c | 18 ++
xen/common/page_alloc.c| 24
xen/common/sysctl.c|
On x86, mfn_to_gmfn can be replaced with mfn_to_gfn. On Arm, there are
no more call to mfn_to_gmfn, so the helper can be dropped.
At the same time rework a comment in Arm code that does not make sense.
Signed-off-by: Julien Grall
---
xen/drivers/passthrough/iommu.c | 6 +++---
xen/include/asm-a
No functional changes intended.
Signed-off-by: Julien Grall
---
xen/common/grant_table.c | 4 ++--
xen/include/asm-arm/grant_table.h | 12 ++--
xen/include/asm-x86/grant_table.h | 20
3 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/xen/comm
While Arm never had a M2P, the implementation of mfn_to_gmfn is pretty
bogus as we directly return the MFN passed in parameter.
Thankfully, the use of mfn_to_gmfn is pretty limited on Arm today. There
are only 3 callers:
- iommu_hwdom_init: mfn_to_gmfn is used for creating IOMMU
page-table
Hi,
Does anyone know whether Gang Wei left Intel? Do we know an alternative e-mail?
Cheers,
On 18/02/2019 11:36, Mail Delivery System wrote:
This is the mail system at host usa-sjc-mx-foss1.foss.arm.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more r
On 15/02/2019 16:41, Razvan Cojocaru wrote:
> domain_pause_except_self() was introduced to allow a domain to pause
> itself while doing altp2m operations. However, as written, it has a
> risk fo deadlock if two vcpus enter the loop at the same time.
>
> Luckily, there's already a solution for thi
On 15/02/2019 16:41, Razvan Cojocaru wrote:
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
>
> This can lead to domain crashes in the vmx_vmexit_handler
> On 18 Feb 2019, at 11:30, George Dunlap wrote:
>
> On 2/18/19 11:23 AM, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
>>> Thank you Wei. It's interesting though that the full vs HVM only is almost
>>> identical in terms of SLOC's
>>> Lars
>>
>> The cloc targe
On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>
>
> > On 18 Feb 2019, at 11:30, George Dunlap wrote:
> >
> > On 2/18/19 11:23 AM, Wei Liu wrote:
> >> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
> >>> Thank you Wei. It's interesting though that the full vs HVM only
> On 18 Feb 2019, at 11:57, Wei Liu wrote:
>
> On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>>
>>
>>> On 18 Feb 2019, at 11:30, George Dunlap wrote:
>>>
>>> On 2/18/19 11:23 AM, Wei Liu wrote:
On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
> Thank you We
On 18/02/2019 11:57, Wei Liu wrote:
> On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>>
>>> On 18 Feb 2019, at 11:30, George Dunlap wrote:
>>>
>>> On 2/18/19 11:23 AM, Wei Liu wrote:
On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
> Thank you Wei. It's interesting
> On 18 Feb 2019, at 12:01, Andrew Cooper wrote:
>
> On 18/02/2019 11:57, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>>>
On 18 Feb 2019, at 11:30, George Dunlap wrote:
On 2/18/19 11:23 AM, Wei Liu wrote:
> On Mon, Feb 18, 2019 at 11:17:56
On 2/18/19 12:01 PM, Andrew Cooper wrote:
> On 18/02/2019 11:57, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>>>
On 18 Feb 2019, at 11:30, George Dunlap wrote:
On 2/18/19 11:23 AM, Wei Liu wrote:
> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars
On 2/18/19 11:05 AM, Roger Pau Monné wrote:
> On Fri, Feb 15, 2019 at 07:15:53PM +0100, George Dunlap wrote:
>>
>>
>>> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
>>>
>>> So that the specific handling can be removed from
>>> atomic_write_ept_entry and be shared with npt and shadow code.
>>
On 2/18/19 12:11 PM, George Dunlap wrote:
> On 2/18/19 12:01 PM, Andrew Cooper wrote:
>> On 18/02/2019 11:57, Wei Liu wrote:
>>> On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
> On 18 Feb 2019, at 11:30, George Dunlap wrote:
>
> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>
On 2/18/19 11:01 AM, Roger Pau Monné wrote:
> On Fri, Feb 15, 2019 at 06:48:25PM +0100, George Dunlap wrote:
>>
>>> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
>>>
>>> This is in preparation for also changing p2m_entry_modify to return an
>>> error code.
>>>
>>> No functional change intend
On 2/15/19 2:18 PM, Roger Pau Monne wrote:
> So that it can be shared by both ept, npt and shadow code, instead of
> duplicating it.
>
> No change in functionality intended.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Paul Durrant
There's part of me that feels like this patch wants some
Hi,
> I am wondering what Android version you are using. What is your use-case?
We are trying with Android O 8.1 version.
> This is our development product
> https://github.com/xen-troops/meta-xt-prod-devel
> which in addition to Linux guest contains Android P guest.
>
After making some changes i
> On 18 Feb 2019, at 12:16, George Dunlap wrote:
>
> On 2/18/19 12:11 PM, George Dunlap wrote:
>> On 2/18/19 12:01 PM, Andrew Cooper wrote:
>>> On 18/02/2019 11:57, Wei Liu wrote:
On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>
>> On 18 Feb 2019, at 11:30, George Dun
Hi,
On 26/01/2019 08:53, Amit Singh Tomar wrote:
As pointed out by Andre on the previous version, the commit message is missing.
Among things that a commit message could describe is:
- Link to the specification
- Why we don't need to initialize the UART. I know we discussed about it on
Hi Amit,
I will leave Andre to properly review the driver. But see the some comments
below.
On 26/01/2019 08:53, Amit Singh Tomar wrote:
This patch adds driver for UART controller present on Amlogic Meson
SoCs and it has been tested on Nanopi K2 board based on S905 SoC.
Controller registers d
On 2/15/19 11:34, Jan Beulich wrote:
On 15.02.19 at 10:55, wrote:
>> On 2/13/19 12:50, Jan Beulich wrote:
>> On 08.02.19 at 14:44, wrote:
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
sp
Hi,
On 01/02/2019 12:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Ol
Hi,
On 01/02/2019 12:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
In general a patch should do only one thing. In this case, this should have been
split in 2 patches: one to extend the driver, the second to a
Hi,
On 01/02/2019 12:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SCIF UART support (debug-scif.inc) and
newly added SCIFA UART support (debug-scifa.inc) di
Hi, Dario
[sorry for the html email format, resend by text.]
> On Fri, 2019-02-15 at 06:15 +, zheng chuan wrote:
> > Hi, Dario,
> >
> Hi,
>
> > Here is the xentrace in credit2 with ratelimiting 1 ms and 30ms by
> > observing 1 seconds both.
> >
> Ok, thanks a lot for doing this! I'm doing my o
On Fri, Feb 15, 2019 at 09:38:59PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/15/19 5:25 PM, Paul Durrant wrote:
> > The if() statement is clearly bogus (dead code which should have been
> > cleaned up when grant mapping was removed).
>
> "... was removed in 06454c24ad)."
Actually, it looks like
flight 133284 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133284/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132847
test-armhf-armhf-libvirt 14 sav
On Fri, Feb 15, 2019 at 04:25:32PM +, Paul Durrant wrote:
> The assignment to 'p' is unnecessary as the code will either goto 'invalid'
> or p will get overwritten.
>
> Spotted by Coverity: CID 1398638
>
> Reported-by: Peter Maydell
> Signed-off-by: Paul Durrant
Acked-by: Anthony PERARD
On 2/15/19 12:46, Jan Beulich wrote:
On 15.02.19 at 11:50, wrote:
>> On 2/15/19 09:55, Jan Beulich wrote:
>> On 15.02.19 at 09:05, wrote:
On 2/12/19 15:14, Jan Beulich wrote:
On 12.02.19 at 15:05, wrote:
>> On 2/12/19 14:25, Jan Beulich wrote:
>> On 08.02.19 at
Hi all,
Xen 4.12 rc3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12.0-rc3
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc3/xen-4.12.0-rc3.tar.gz
And the signature is at:
https://downloads.xenproject.org/
On Fri, Feb 15, 2019 at 04:25:33PM +, Paul Durrant wrote:
> The function needs to make sure it is passed a valid disk name. This is
> easily done by making sure that the parsing loop results in a non-zero
> value.
>
> Spotted by Coverity: CID 1398640
>
> Reported-by: Peter Maydell
> Signed-o
>>> On 18.02.19 at 15:47, wrote:
> On 2/15/19 12:46, Jan Beulich wrote:
>> A code change is, imo, not even worthwhile considering to be put
>> in if it is solely based on the observations made with a limited set
>> of compilers and/or options. This might indeed help you, if you
>> care only about
>>> On 18.02.19 at 14:49, wrote:
> On 2/15/19 11:34, Jan Beulich wrote:
> On 15.02.19 at 10:55, wrote:
>>> On 2/13/19 12:50, Jan Beulich wrote:
>>> On 08.02.19 at 14:44, wrote:
> Guests can issue grant table operations and provide guest controlled
> data to them. This data is als
It's unsafe to disable IOMMU on a live system which is the case
if we're crashing since remapping hardware doesn't usually know what
to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
etc. (depends on the firmware configuration) to signal these abnormalities.
This, in turn, does
Avoid printing a warning message when writing to a BAR register with
memory decoding enabled if the value written is the same as the
current one.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc:
Sorry for the rather random CC list.
Last year we bought a variety of test boxes. Amongst them were three
biggish Intel machines which I had primarily intended for use as
dedicated build servers. These are himrod[012].
Unfortunately I have not been able to commission them because they
have been
flight 133301 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133301/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 18.02.19 at 17:24, wrote:
> Avoid printing a warning message when writing to a BAR register with
> memory decoding enabled if the value written is the same as the
> current one.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
with one cosmetic ques
On Mon, Feb 18, 2019 at 09:45:07AM -0700, Jan Beulich wrote:
> >>> On 18.02.19 at 17:24, wrote:
> > Avoid printing a warning message when writing to a BAR register with
> > memory decoding enabled if the value written is the same as the
> > current one.
> >
> > No functional change.
> >
> > Sign
>>> On 18.02.19 at 17:27, wrote:
> The symptom is that, occasionally, the network stops working for a
> while. It then comes back, spontaneously. There are no log messages
> recorded on the box itself in /var/log for this; no messages on the
> serial console.
>
> The failure probability is abou
>>> On 18.02.19 at 17:53, wrote:
> On Mon, Feb 18, 2019 at 09:45:07AM -0700, Jan Beulich wrote:
>> >>> On 18.02.19 at 17:24, wrote:
>> > @@ -381,6 +371,19 @@ static void bar_write(const struct pci_dev *pdev,
>> > unsigned int reg,
>> > else
>> > val &= PCI_BASE_ADDRESS_MEM_MASK;
>>
So that it can be shared by both ept, npt and shadow code, instead of
duplicating it.
No change in functionality intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Reviewed-by: George Dunlap
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Jun Nakajim
Current npt and shadow code to get an entry will always return
INVALID_MFN for foreign entries. Allow to return the entry mfn for
foreign entries, like it's done for grant table entries.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
Cha
The remaining set of patches contain changes to the p2m code that could
affect HVM guests. Note that without those changes a PVH dom0 running on
AMD hardware will be unable to create guests. Overall the patches are a
nice cleanup to the handling of p2m_ioreq_server and p2m_map_foreign
types IMO.
T
So that the specific handling can be removed from
atomic_write_ept_entry and be shared with npt and shadow code.
This commit also removes the check that prevent non-ept PVH dom0 from
mapping foreign pages.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
This is in preparation for also changing p2m_entry_modify to return an
error code.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Tim Deegan
---
Changes since v3:
- Use asserts instead of bugs to check r
flight 133285 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133285/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl-qemuu-
On 18/02/2019 16:21, Igor Druzhinin wrote:
> It's unsafe to disable IOMMU on a live system which is the case
> if we're crashing since remapping hardware doesn't usually know what
> to do with ongoing bus transactions and frequently raises NMI/MCE/SMI,
> etc. (depends on the firmware configuration)
On 18.02.19 14:53, Amit Tomer wrote:
Hi
Hi,
I am wondering what Android version you are using. What is your use-case?
We are trying with Android O 8.1 version.
This is our development product
https://github.com/xen-troops/meta-xt-prod-devel
which in addition to Linux guest contains Android
On 18.02.19 16:00, Julien Grall wrote:
Hi,
Hi
On 01/02/2019 12:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend existing driver to be able to handle SCIFA interface as well.
In general a patch should do only one thing. In this case, this should
have been split in 2 p
flight 133287 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
test-amd64-a
On 18.02.19 16:05, Julien Grall wrote:
Hi,
Hi
On 01/02/2019 12:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SCIF UART support (debug-scif.inc) and
n
On 18.02.19 22:41, Oleksandr wrote:
On 18.02.19 16:05, Julien Grall wrote:
Hi,
Hi
On 01/02/2019 12:37, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add support for Renesas "Stout" development board based on
R-Car H2 SoC which has SCIFA compatible UART.
Actually existing SC
flight 133291 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133291/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c417c1b33d06ef6ae96adb373201a5a3c3b38772
baseline version:
ovmf 64a17fadcb79e2ce40524
flight 133288 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 133132
build-arm64
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, February 19, 2019 1:27 AM
>
> So that it can be shared by both ept, npt and shadow code, instead of
> duplicating it.
>
> No change in functionality intended.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Paul Durrant
>
This case block will be terminated by a break, so not need
a switch fall-through
Signed-off-by: Li RongQing
---
sound/xen/xen_snd_front.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/xen/xen_snd_front.c b/sound/xen/xen_snd_front.c
index a9e5c2cd7698..f12fb8eeaa27 100644
--- a/sound/x
flight 133290 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133290/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
test-amd64-i
flight 133299 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133299/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd cdb7673abfefda182ace24a3abd1a04d1a16dd79
baseline version:
freebsd c9afb7f6b36
On 18/02/2019 17:24, Roger Pau Monne wrote:
> Avoid printing a warning message when writing to a BAR register with
> memory decoding enabled if the value written is the same as the
> current one.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Release-acked-by: Juergen Gross
Jue
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Tuesday, February 19, 2019 1:27 AM
>
> So that the specific handling can be removed from
> atomic_write_ept_entry and be shared with npt and shadow code.
>
> This commit also removes the check that prevent non-ept PVH dom0 from
> mappi
1 - 100 of 102 matches
Mail list logo
