flight 130750 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
flight 130745 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
>>> On 23.11.18 at 15:36, wrote:
> On Thu, Nov 22, 2018 at 06:20:46AM -0700, Jan Beulich wrote:
>> >>> On 22.11.18 at 13:47, wrote:
>> > I think the is_hardware_domain part can be dropped from the
>> > conditional I'm adding. update_paging_mode shouldn't be used to decide
>> > whether a domain ca
flight 130805 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
Since the behavior of "diff -p" to use an unindented label as context
identifier often makes it harder to review patches, make explicit the
requirement for labels to be indented.
Signed-off-by: Jan Beulich
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -31,6 +31,10 @@ void fun(void)
}
}
+Due t
...for N in {8, 16, 32, 64}.
Bring the coding style up to date. No functional change.
Also, while in the neighbourhood, fix some tabs.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 115
Bring the coding style up to date. No functional change.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/xen/drivers/passthrough/
>>> On 23.11.18 at 17:03, wrote:
> On 23/11/2018 08:23, Jan Beulich wrote:
> On 22.11.18 at 18:46, wrote:
>>> On 22/11/2018 14:51, Jan Beulich wrote:
> @@ -220,12 +219,18 @@ void guest_iommu_add_ppr_log(struct domain *d, u32
> entry[])
> unmap_domain_page(log_base);
>
No functional change.
Paul Durrant (2):
amd-iommu: replace occurrences of bool_t with bool
amd-iommu: replace occurrences of u with uint_t...
xen/drivers/passthrough/amd/iommu_map.c | 137
1 file changed, 70 insertions(+), 67 deletions(-)
---
Cc: Suravee Su
Signed-off-by: Jan Beulich
---
v2: Drop signed-ness requirement.
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -88,6 +88,19 @@ Braces should be omitted for blocks with
if ( condition )
single_statement();
+Types
+-
+
+Use basic C types and C standard mandated typedef-s where possible (and
>>> On 26.11.18 at 10:05, wrote:
> @@ -123,13 +123,13 @@ static bool_t set_iommu_pde_present(u32 *pde, unsigned
> long next_mfn,
> return need_flush;
> }
>
> -static bool_t set_iommu_pte_present(unsigned long pt_mfn, unsigned long dfn,
> -unsigned long
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 09:39
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH 1/2] amd-iommu: replace occurrences of
> bool_t with
>>> On 26.11.18 at 10:05, wrote:
> @@ -127,24 +127,25 @@ static bool set_iommu_pte_present(unsigned long pt_mfn,
> unsigned long dfn,
>unsigned long next_mfn, int pde_level,
>bool iw, bool ir)
> {
> -u64 *table;
> -u
>>> On 26.11.18 at 10:40, wrote:
> Thanks. Are you happy to fix up on commit or would you like a v2?
To be honest in this case I'd prefer a v2.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listin
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 09:51
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH 1/2] amd-iommu: replace occurrences of
> bool_t with
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 09:46
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH 2/2] amd-iommu: replace occurrences of
> u with uint_
>>> On 23.11.18 at 15:30, wrote:
> LLVM code generation can attempt to load from a variable in the next
> condition of an expression under certain circumstances, thus turning
> the following condition:
>
> if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE )
>
> Into:
>
> 0
On Fri, Nov 23, 2018 at 06:35:18PM +0100, Roger Pau Monné wrote:
> On Fri, Nov 23, 2018 at 04:25:00PM +, Wei Liu wrote:
> > On Fri, Nov 23, 2018 at 04:18:41PM +, Wei Liu wrote:
> > > On Fri, Nov 23, 2018 at 03:28:49PM +, Anthony PERARD wrote:
> > > > > diff --git a/tools/hotplug/Linux/s
>>> On 25.11.18 at 20:14, wrote:
> My notebook reports a display size of 1920x1080:
>
> (XEN) vesafb: framebuffer at 0xd000, mapped to 0x82c000201000, using
> 8128k, total 8128k
> (XEN) vesafb: mode is 1920x1080x32, linelength=7680, font 8x16
> (XEN) vesafb: Truecolor: size=8:8:8:8, shif
Introduce XEN_DOM0_UUID in Xen's global configuration file. Make
xen-init-dom0 accept an extra argument for UUID.
Also switch xs_open error message to use perror.
Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Reviewed-by: Sergey Dyasli
---
v4:
1. use perror
2. added Rb from Juergen and Se
flight 75621 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 75589
test-armhf-armhf-armhf-sid-netboot-pygr
>>> On 23.11.18 at 14:25, wrote:
> In debug builds the hypervisor will deliberately clobber processed
> elements of the multicall structure. In order to ease diagnostic data
> printout in the affected guest only clobber elements which didn't
> return an error.
Besides what Andrew has said such a
>>> On 20.11.18 at 17:01, wrote:
> When switching the memory decoding bit in the command register the
> rest of the changes where dropped, leading to only the memory decoding
> bit being updated.
>
> Fix this by writing the command register once the guest physmap
> manipulations are done if there
osstest service owner writes ("[osstest test] 130741: regressions - FAIL"):
> flight 130741 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/130741/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-
>>> On 20.11.18 at 17:01, wrote:
> Current logic to handle long running operations is flawed because it
> doesn't prevent the guest vcpu from running. Fix this by raising a
> scheduler softirq when preemption is required, so that the do_softirq
> call in the guest entry path performs a reschedulin
flight 130808 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6 xen
>>> On 20.11.18 at 17:01, wrote:
> No functional change expected.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Paul Durrant (2):
amd-iommu: replace occurrences of bool_t with bool
amd-iommu: replace occurrences of u with uint_t...
xen/drivers/passthrough/amd/iommu_map.c | 148 +-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
2 files changed, 77 insertions(+), 73
...for N in {8, 16, 32, 64}.
Bring the coding style up to date.
Also, while in the neighbourhood, fix some tabs and remove use of uint64_t
values where it leads to the need for explicit casting.
Signed-off-by: Paul Durrant
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
v2:
- Remove some uses
Bring the coding style up to date. No functional change (except for
removal of some pointless initializers).
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
---
xen/drivers/passthrough/amd/iommu_map.c | 26 +-
1 file c
>>> On 20.11.18 at 17:01, wrote:
> Current logic to handle long running operations is flawed because it
> doesn't prevent the guest vcpu from running. Fix this by raising a
> scheduler softirq when preemption is required, so that the do_softirq
> call in the guest entry path performs a reschedulin
>>> On 26.11.18 at 12:32, wrote:
> @@ -306,7 +307,8 @@ void iommu_dte_set_guest_cr3(u32 *dte, u16 dom_id, u64
> gcr3,
> uint64_t amd_iommu_get_address_from_pte(void *pte)
> {
> uint32_t *entry = pte;
> -uint64_t addr_lo, addr_hi, ptr;
> +uint32_t addr_lo, addr_hi;
> +uint64_t p
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 11:49
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH v2 2/2] amd-iommu: replace occurrences of
> u with ui
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 November 2018 11:42
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Tim (Xen.o
c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
introduced a TypeError when changing how Fail exceptions were printed:
/local/xen.git/xen/../xen/tools/gen-cpuid.py:Traceback (most recent call
last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 483, in
On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
> >>> On 23.11.18 at 15:30, wrote:
> > LLVM code generation can attempt to load from a variable in the next
> > condition of an expression under certain circumstances, thus turning
> > the following condition:
> >
> > if ( system_state
>>> On 22.11.18 at 12:40, wrote:
> The logdirty rangesets of the altp2ms need to be kept in sync with the
> hostp2m. This means when iterating through the altp2ms, we need to
> use the host p2m to clip the rangeset, not the indiviual altp2m's
> value.
>
> This change also:
>
> - Documents that
>>> On 22.11.18 at 12:40, wrote:
> @@ -956,18 +1003,14 @@ int p2m_change_type_one(struct domain *d, unsigned
> long gfn_l,
> }
>
> /* Modify the p2m type of a range of gfns from ot to nt. */
> -void p2m_change_type_range(struct domain *d,
> - unsigned long start, un
Hello, all!
My driver (Xen para-virtualized frontend) in some scenarios uses
drm_gem_get_pages for allocating backing storage for dumb buffers.
There are use-cases which showed some artifacts on the screen
(modetest, other) which were worked around by flushing pages of the
buffer on page flip wit
>>> On 26.11.18 at 13:04, wrote:
> On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
>> >>> On 23.11.18 at 15:30, wrote:
>> > LLVM code generation can attempt to load from a variable in the next
>> > condition of an expression under certain circumstances, thus turning
>> > the followin
On Mon, Nov 26, 2018 at 12:03:07PM +, Andrew Cooper wrote:
> c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
> introduced a TypeError when changing how Fail exceptions were printed:
>
> /local/xen.git/xen/../xen/tools/gen-cpuid.py:Traceback (most recent call
> last):
>
>>> On 20.11.18 at 15:37, wrote:
> With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into the common
> code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
> msr_tsc_aux), and add an RDPID feature check as this bit also enumerates the
> presence of the MSR.
>
> Intr
On Mon, Nov 26, 2018 at 10:40:44AM +, Wei Liu wrote:
> Introduce XEN_DOM0_UUID in Xen's global configuration file. Make
> xen-init-dom0 accept an extra argument for UUID.
>
> Also switch xs_open error message to use perror.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Juergen Gross
> Reviewed
Hi Jan,
On 26/11/2018 12:18, Jan Beulich wrote:
On 26.11.18 at 13:04, wrote:
On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
On 23.11.18 at 15:30, wrote:
LLVM code generation can attempt to load from a variable in the next
condition of an expression under certain circumstances,
On 23.11.18 19:06, Michal Suchánek wrote:
> On Fri, 23 Nov 2018 12:13:58 +0100
> David Hildenbrand wrote:
>
>> On 28.09.18 17:03, David Hildenbrand wrote:
>>> How to/when to online hotplugged memory is hard to manage for
>>> distributions because different memory types are to be treated different
flight 130752 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130752/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
>>> On 26.11.18 at 13:25, wrote:
> May I ask what are the downsides? Do you expect a lot of false positive?
Having to split code paths, to introduce redundancy, or to move
code/data out of .init.* that could in fact live there are all
possible issues. Plus the __ref{,data} annotation that Linux h
>>> On 26.11.18 at 13:17, wrote:
> On Mon, Nov 26, 2018 at 12:03:07PM +, Andrew Cooper wrote:
>> c/s 18596903 "xen/tools: support Python 2 and Python 3" unfortunately
>> introduced a TypeError when changing how Fail exceptions were printed:
>>
>> /local/xen.git/xen/../xen/tools/gen-cpuid.py
On Mon, Nov 26, 2018 at 05:18:20AM -0700, Jan Beulich wrote:
> >>> On 26.11.18 at 13:04, wrote:
> > On Mon, Nov 26, 2018 at 03:06:16AM -0700, Jan Beulich wrote:
> >> >>> On 23.11.18 at 15:30, wrote:
> >> > LLVM code generation can attempt to load from a variable in the next
> >> > condition of an
>>> On 22.11.18 at 12:40, wrote:
> change_range_type() invalidates gfn ranges to lazily change the type
Would you mind correcting the function name here?
> of a range of gfns, and also modifies the logdirty rangesets of that
> p2m. At the moment, it clips both down by the hostp2m.
>
> While thi
>>> On 26.11.18 at 13:49, wrote:
> On Mon, Nov 26, 2018 at 05:18:20AM -0700, Jan Beulich wrote:
>> Furthermore I doubt writing this down would help, because for
>> such apparently simple things no-one goes hunt for related
>> documentation. I think the only future proof course of action
>> would b
>>> On 23.11.18 at 17:52, wrote:
> No functional change, as the value returned was previously always 0 or 1.
> While altering these, insert blank lines where appropriate and drop the
> now-redundant !! from x86's local_irq_is_enabled().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Anyone else seeing this, or is it just me? This was on a fresh pull of staging
about 5 mins ago...
make -C x86_emulator distclean
make[5]: Entering directory '/local/scratch/pauldu/xen/tools/tests/x86_emulator'
make -C 32 clean
make[6]: Entering directory
'/local/scratch/pauldu/xen/tools/tests/x
>>> On 23.11.18 at 17:52, wrote:
> --- a/xen/include/asm-x86/system.h
> +++ b/xen/include/asm-x86/system.h
> @@ -253,14 +253,18 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> /* used when interrupts are already enabled or to shutdown the processor */
> #define h
On Wed, 7 Nov 2018 16:36:48 +0400
Marc-André Lureau wrote:
> It's now possible to use the common function.
>
> Teach object_apply_global_props() to warn if Error argument is NULL.
>
> Signed-off-by: Marc-André Lureau
> ---
> hw/core/qdev-properties.c | 24 ++--
> qom/obje
There is a circular link formed between domain and a connection. In certain
circustances, when conn is freed, domain is also freed, which leads to use
after free when trying to set the conn field in domain to null.
Signed-off-by: Petre Eftime
---
tools/xenstore/xenstored_domain.c | 9 -
>>> On 23.11.18 at 17:52, wrote:
> ... rather than a macro which writes to its parameter by name. Take the
> opportunity to fold the assignment into the flags declaraion where
> appropriate.
Do you really? Why not ...
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -401,7 +401,7 @@ voi
>>> On 23.11.18 at 17:52, wrote:
> RFC, as I expect this patch to get some objection for removing the IRQ safety
> check, but the only reasons that change was made in e5fc6434d7 was because I
> talk talked into doing it while trying to clean up some unnecessary use of
> magic numbers.
>
> No user
On 26.11.18 13:30, David Hildenbrand wrote:
> On 23.11.18 19:06, Michal Suchánek wrote:
>> On Fri, 23 Nov 2018 12:13:58 +0100
>> David Hildenbrand wrote:
>>
>>> On 28.09.18 17:03, David Hildenbrand wrote:
How to/when to online hotplugged memory is hard to manage for
distributions because
>>> On 26.11.18 at 14:04, wrote:
> Anyone else seeing this, or is it just me? This was on a fresh pull of
> staging about 5 mins ago...
I don't think I ever ran distclean, but I think I can see the issue.
Would you mind trying
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulat
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 26 November 2018 13:41
> To: Paul Durrant
> Cc: xen-devel
> Subject: Re: [Xen-devel] x86_emulator distclean failing
>
> >>> On 26.11.18 at 14:04, wrote:
> > Anyone e
On 26/11/2018 11:58, Jan Beulich wrote:
On 23.11.18 at 14:25, wrote:
>> In debug builds the hypervisor will deliberately clobber processed
>> elements of the multicall structure. In order to ease diagnostic data
>> printout in the affected guest only clobber elements which didn't
>> return an
On Wed, 7 Nov 2018 16:36:38 +0400
Marc-André Lureau wrote:
> Hi,
>
> During "[PATCH v2 05/10] qom/globals: generalize
> object_property_set_globals()" review, Eduardo suggested to rework the
> GlobalProperty handling, so that -global is limited to QDev only and
> we avoid mixing the machine com
>>> On 26.11.18 at 14:52, wrote:
> I don't think the hypervisor should explicitly try to make it as hard as
> possible for the guest to find problems in the code.
That's indeed not the hypervisor's goal. Instead it tries to make
it as hard as possible for the guest (developer) to make wrong
assum
When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
switch around the use in the expression controlling the rule
dependencies, causin
On 26/11/2018 14:13, Jan Beulich wrote:
> When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
> 32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
> instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
> switch around the use in the expr
On Mon, 26 Nov 2018 14:33:29 +0100
David Hildenbrand wrote:
> On 26.11.18 13:30, David Hildenbrand wrote:
> > On 23.11.18 19:06, Michal Suchánek wrote:
> >>
> >> If we are going to fake the driver information we may as well add the
> >> type attribute and be done with it.
> >>
> >> I think the
flight 130811 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130811/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 130289
Tests which
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
>> I don't think the hypervisor should explicitly try to make it as hard as
>> possible for the guest to find problems in the code.
>
> That's indeed not the hypervisor's goal. Instead it tries to make
> it as hard as possi
On Mon, Nov 26, 2018 at 07:13:33AM -0700, Jan Beulich wrote:
> When preparing what is now 52c37f7ab9 ("x86emul: also allow running the
> 32-bit harness on a 64-bit distro") I first wrongly used XEN_TARGET_ARCH
> instead of XEN_COMPILE_ARCH. When realizing the mistake I forgot to also
> switch aroun
On Fri, Nov 23, 2018 at 11:30:39PM +0800, Mao Zhongyi wrote:
> The init function doesn't do anything at all, so we
> just omit it.
>
> Cc: sstabell...@kernel.org
> Cc: anthony.per...@citrix.com
> Cc: xen-devel@lists.xenproject.org
> Cc: peter.mayd...@linaro.org
>
> Signed-off-by: Mao Zhongyi
> S
On Fri, Nov 23, 2018 at 04:57:08PM +0100, Olaf Hering wrote:
> Am Fri, 23 Nov 2018 15:54:49 +
> schrieb Anthony PERARD :
>
> > Is your toolstack runs the QMP command 'query-block' or some other
> > command related to block behind libxl's back?
>
> This is plain xl create + xl migrate from sta
Whilst attempting to crash an apparently wedged Windows domain using
'xen-hvmcrash' I managed to trigger the following ASSERT:
(XEN) Assertion '!vp->ptr' failed at viridian.c:607
with stack:
(XEN)[] viridian_map_guest_page+0x1b4/0x1b6
(XEN)[] viridian_synic_load_vcpu_ctxt+0x39/0x3b
(XEN)
Jan Beulich writes ("Re: [PATCH] xen: only clobber multicall elements without
error"):
> On 23.11.18 at 14:25, wrote:
> > In debug builds the hypervisor will deliberately clobber processed
> > elements of the multicall structure. In order to ease diagnostic data
> > printout in the affected guest
>>> On 26.11.18 at 15:23, wrote:
> On 26/11/2018 15:01, Jan Beulich wrote:
> On 26.11.18 at 14:52, wrote:
>>> I don't think the hypervisor should explicitly try to make it as hard as
>>> possible for the guest to find problems in the code.
>>
>> That's indeed not the hypervisor's goal. Inste
Every invocation of xl via valgrind will show three leaks. Since
libxl_bitmap_alloc uses NOGC, the caller has to free the memory after
use.
Signed-off-by: Olaf Hering
---
tools/xl/xl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/xl/xl.c b/tools/xl/xl.c
index 7d2142f16f..9756a835
Am Mon, 26 Nov 2018 15:58:22 +0100
schrieb Olaf Hering :
> +++ b/tools/xl/xl.c
> @@ -229,6 +229,9 @@ static void parse_global_config(const char *configfile,
Actually I think that should go to xl_ctx_free() instead. I moved it down to
parse_global_config() by accident.
Olaf
pgptRsIXARFmB.pgp
D
On Mon, Nov 26, 2018 at 02:54:54PM +, Paul Durrant wrote:
> Whilst attempting to crash an apparently wedged Windows domain using
> 'xen-hvmcrash' I managed to trigger the following ASSERT:
>
> (XEN) Assertion '!vp->ptr' failed at viridian.c:607
>
> with stack:
>
> (XEN)[] viridian_map_gu
On Mon, Nov 19, 2018 at 04:26:58PM +, Peter Maydell wrote:
> Coverity (CID 796599) points out that xen_pt_setup_vga() trusts
> the rom->size field in the BIOS ROM from a PCI passthrough VGA
> device, and uses it as an index into the memory which contains
> the BIOS image. A corrupt BIOS ROM cou
> -Original Message-
> From: Roger Pau Monne
> Sent: 26 November 2018 15:04
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; Wei Liu
> Subject: Re: [PATCH] viridian: fix assertion failure
>
> On Mon, Nov 26, 2018 at 02:54:54PM +, Paul Durrant w
Am Mon, 26 Nov 2018 14:32:05 +
schrieb Anthony PERARD :
> Also, a backtrace of the original problem would be nice.
There is no backtrace, all the data I could grab was sent to this list.
I was unable to reproduce it as well.
Olaf
pgpL73JOm72zk.pgp
Description: Digitale Signatur von OpenPGP
On Mon, Nov 26, 2018 at 04:04:08PM +0100, Olaf Hering wrote:
> Am Mon, 26 Nov 2018 15:58:22 +0100
> schrieb Olaf Hering :
>
> > +++ b/tools/xl/xl.c
> > @@ -229,6 +229,9 @@ static void parse_global_config(const char *configfile,
>
> Actually I think that should go to xl_ctx_free() instead. I moved
On 26/11/2018 15:54, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] xen: only clobber multicall elements without
> error"):
>> On 23.11.18 at 14:25, wrote:
>>> In debug builds the hypervisor will deliberately clobber processed
>>> elements of the multicall structure. In order to ease diagn
On Thu, Nov 15, 2018 at 09:47:17PM +, Andy Cooper wrote:
> With PVRDTSCP mode removed, handling of MSR_TSC_AUX can move into the common
> code. Move its storage into struct vcpu_msrs (dropping the HVM-specific
> msr_tsc_aux), and add an RDPID feature check as this bit also enumerates the
> pre
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
>> On 26/11/2018 15:01, Jan Beulich wrote:
>> On 26.11.18 at 14:52, wrote:
I don't think the hypervisor should explicitly try to make it as hard as
possible for the guest to find problems in the code.
>>>
>>>
On Mon, Nov 26, 2018 at 09:05:25AM +, Paul Durrant wrote:
> Bring the coding style up to date. No functional change.
>
> Signed-off-by: Paul Durrant
Acked-by: Brian Woods
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Mon, Nov 26, 2018 at 03:08:50PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 26 November 2018 15:04
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> > Andrew Cooper ; Wei Liu
> > Subject: Re: [PATCH] viridian: fix ass
On Mon, Nov 26, 2018 at 09:35:26AM -0600, Brian Woods wrote:
> On Mon, Nov 26, 2018 at 09:05:25AM +, Paul Durrant wrote:
> > Bring the coding style up to date. No functional change.
> >
> > Signed-off-by: Paul Durrant
>
> Acked-by: Brian Woods
>
> --
> Brian Woods
Meant for another patch
> -Original Message-
> From: Roger Pau Monne
> Sent: 26 November 2018 15:32
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ;
> Andrew Cooper ; Wei Liu
> Subject: Re: [PATCH] viridian: fix assertion failure
>
> On Mon, Nov 26, 2018 at 03:08:50PM +, Paul Durrant w
On Thu, 22 Nov 2018 00:27:33 +0100
Samuel Ortiz wrote:
> On Thu, Nov 15, 2018 at 02:28:54PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:38 +0100
> > Samuel Ortiz wrote:
> >
> > > This is the standard way of building SRAT on x86 platfoms. But future
> > > machine types could deci
A top level "make build", as used e.g. by osstest, wants to build all
"all" targets in enabled tools subdirectories, which by default also
includes the emulator test harness. The use of, in particular, {evex}
insn pseudo-prefixes in, again in particular, test_x86_emulator.c causes
this build to fai
Whilst attempting to crash an apparently wedged Windows domain using
'xen-hvmcrash' I managed to trigger the following ASSERT:
(XEN) Assertion '!vp->ptr' failed at viridian.c:607
with stack:
(XEN)[] viridian_map_guest_page+0x1b4/0x1b6
(XEN)[] viridian_synic_load_vcpu_ctxt+0x39/0x3b
(XEN)
Juergen Gross writes ("Re: [PATCH] xen: only clobber multicall elements without
error"):
> On 26/11/2018 15:54, Ian Jackson wrote:
> > Maybe they could be clobbered losslessly ? Eg, by xoring with 0xaa or
> > something.
>
> This would be rather hacky: I'd need to find out if clobbering was
> per
On Wed, Nov 21, 2018 at 01:21:18PM +, Andy Cooper wrote:
> Seemingly, a majority of users either override the helpers anyway, or have an
> gfn_t in their hands.
>
> Update the API, and adjust all users to match.
>
> Doing this highlighted a gaping altp2m security hole in
> vmx_vcpu_update_vmf
On 26.11.18 15:20, Michal Suchánek wrote:
> On Mon, 26 Nov 2018 14:33:29 +0100
> David Hildenbrand wrote:
>
>> On 26.11.18 13:30, David Hildenbrand wrote:
>>> On 23.11.18 19:06, Michal Suchánek wrote:
>
If we are going to fake the driver information we may as well add the
type a
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
I don't think the hypervisor should explicitly try to make it as hard as
possible for the guest to find probl
Am Mon, 26 Nov 2018 03:31:27 -0700
schrieb "Jan Beulich" :
> And I think a change like this should (a) address the more general
> case rather than just your laptop (or laptops in general) and (b)
> actually add some headroom. Hence at the very least I'd see us
> go to 4096x3072. WHUXGA would even
On Mon, Nov 26, 2018 at 03:38:52PM +, Paul Durrant wrote:
> Whilst attempting to crash an apparently wedged Windows domain using
> 'xen-hvmcrash' I managed to trigger the following ASSERT:
>
> (XEN) Assertion '!vp->ptr' failed at viridian.c:607
>
> with stack:
>
> (XEN)[] viridian_map_gu
>>> On 26.11.18 at 17:03, wrote:
> Am Mon, 26 Nov 2018 03:31:27 -0700
> schrieb "Jan Beulich" :
>
>> And I think a change like this should (a) address the more general
>> case rather than just your laptop (or laptops in general) and (b)
>> actually add some headroom. Hence at the very least I'd s
On 26/11/2018 17:01, Julien Grall wrote:
>
>
> On 26/11/2018 15:29, Juergen Gross wrote:
>> On 26/11/2018 15:58, Jan Beulich wrote:
>> On 26.11.18 at 15:23, wrote:
On 26/11/2018 15:01, Jan Beulich wrote:
On 26.11.18 at 14:52, wrote:
>> I don't think the hypervisor should e
1 - 100 of 125 matches
Mail list logo
