On Thu, Nov 15, 2018 at 11:40:39AM +0100, Roger Pau Monné wrote:
>On Thu, Nov 15, 2018 at 09:10:26AM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> the only way to make it work agai
flight 130174 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On Fri, Nov 16, 2018 at 11:00:30AM +0530, Souptick Joarder wrote:
> On Thu, Nov 15, 2018 at 11:44 PM Randy Dunlap wrote:
> > On 11/15/18 7:45 AM, Souptick Joarder wrote:
> > What is the opposite of vm_insert_range() or even of vm_insert_page()?
> > or is there no need for that?
>
> There is no op
On Thu, Nov 15, 2018 at 11:44 PM Randy Dunlap wrote:
>
> On 11/15/18 7:45 AM, Souptick Joarder wrote:
> > Previouly drivers have their own way of mapping range of
> > kernel pages/memory into user vma and this was done by
> > invoking vm_insert_page() within a loop.
> >
> > As this pattern is comm
flight 130170 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130170/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 130164 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130164/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 129996 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129996/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129514
test-armhf-armhf-libvirt 14 sav
flight 130161 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 130158 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 130154 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130154/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 129986 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-install fail REGR. vs. 129762
Tests which did not
flight 130151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 130148 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
Boris has confirmed that noone appears to be using PVRDTSCP any more, and in
the decade since it was introduced, guest kernel / hardware support has
provided a better alternative.
Andrew Cooper (4):
x86: Begin to remove TSC mode PVRDTSCP
x86/pv: Remove deferred RDTSC{,P} handling in pv_emulate
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.
Drop hvm_msr_tsc_aux() entirely, and use v->arch.m
As noted in c/s 4999bf3e8b "x86/PV: use generic emulator for privileged
instruction handling", these hoops are jumped through to retain the older
behaviour, along with a note suggesting that we should reconsider things.
It does not matter exactly when pv_soft_rdtsc() is called, as Xen's behaviour
For more historical context, see
c/s c17b36d5dc792cfdf59b6de0213b168bec0af8e8
c/s 04656384a1b9714e43db850c51431008e23450d8
PVRDTSCP was an attempt to provide Xen-aware userspace with a stable monotonic
clock, and enough information for said userspace to cope with frequency
changes across migra
The final remnanat of PVRDTSCP is that we would emulate RDTSCP even on
hardware which lacked the instruction. RDTSCP is available on almost all
64-bit x86 hardware.
Remove this emulation, drop the TSC_MODE_PVRDTSCP constant, and allow RDTSCP
in a PV guest's CPUID policy.
Signed-off-by: Andrew Co
Hi,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
PSCI system suspend function shall be invoked to finalize Xen suspend
procedure. Resume entry point, which needs to be passed via 1st argument
of PSCI system suspend call to the EL3, is hyp_resume. For now, hyp_resume
is just a placeholder that w
On 11/15/18 6:57 PM, Stefano Stabellini wrote:
On Wed, 14 Nov 2018, Julien Grall wrote:
On 14/11/2018 23:04, Stefano Stabellini wrote:
On Wed, 14 Nov 2018, Julien Grall wrote:
- return -ENOSYS;
Why do you return -ENOSYS until this patch? Should not have it be 0?
To distinguish th
flight 130144 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130144/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
On 11/15/18 10:26 PM, George Dunlap wrote:
>
>
>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>> wrote:
>>
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The rea
On 11/15/18 7:17 PM, Mirela Simonovic wrote:
Hi Julien,
On Thu, Nov 15, 2018 at 7:23 PM Julien Grall wrote:
Hi Mirela,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
When Dom0 finalizes its suspend procedure the suspend of Xen is
triggered by calling system_suspend(). Dom0 finalizes the su
Hi,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
The resume of Dom0 should always follow Xen's resume. This is
done by unblocking the first vCPU of Dom0.
Please explain why you always need to resume Dom0 afterwards.
Cheers,
--
Julien Grall
___
Xe
Hi,
On 11/15/18 12:35 AM, Stefano Stabellini wrote:
On Wed, 14 Nov 2018, Julien Grall wrote:
On 14/11/2018 22:45, Stefano Stabellini wrote:
On Wed, 14 Nov 2018, Julien Grall wrote:
Hi,
On 13/11/2018 20:44, Stefano Stabellini wrote:
On Mon, 12 Nov 2018, Julien Grall wrote:
(+ Andre)
On 11/
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty
Hi Mirela,
On 11/15/18 11:42 AM, Mirela Simonovic wrote:
Hi Julien,
On Thu, Nov 15, 2018 at 12:38 PM Julien Grall wrote:
Hi,
On 11/15/18 11:10 AM, Mirela Simonovic wrote:
Hi Julien,
On Thu, Nov 15, 2018 at 11:59 AM Julien Grall wrote:
Hi Mirela,
On 11/15/18 10:33 AM, Mirela Simonovic
Hi,
On 11/15/18 7:48 PM, Stefano Stabellini wrote:
On Thu, 15 Nov 2018, Julien Grall wrote:
Hi Stefano,
On 11/15/18 6:44 PM, Stefano Stabellini wrote:
On Thu, 15 Nov 2018, Julien Grall wrote:
Hi,
On 11/15/18 1:19 PM, Andrii Anisov wrote:
So I would prefer to stick with _t which is quite co
flight 130136 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130136/
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 Thu, 15 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/15/18 6:44 PM, Stefano Stabellini wrote:
> > On Thu, 15 Nov 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 11/15/18 1:19 PM, Andrii Anisov wrote:
> > > > > So I would prefer to stick with _t which is quite common within the
> >
On Thu, 15 Nov 2018, Mirela Simonovic wrote:
> Hi Julien,
>
> On Thu, Nov 15, 2018 at 12:38 PM Julien Grall wrote:
> >
> > Hi,
> >
> > On 11/15/18 11:10 AM, Mirela Simonovic wrote:
> > > Hi Julien,
> > >
> > > On Thu, Nov 15, 2018 at 11:59 AM Julien Grall
> > > wrote:
> > >>
> > >> Hi Mirela,
>
flight 130134 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
Hi Julien,
On Thu, Nov 15, 2018 at 7:23 PM Julien Grall wrote:
>
> Hi Mirela,
>
> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > When Dom0 finalizes its suspend procedure the suspend of Xen is
> > triggered by calling system_suspend(). Dom0 finalizes the suspend from
> > its boot core (VCPU#0)
Hi Stefano,
On 11/15/18 6:44 PM, Stefano Stabellini wrote:
On Thu, 15 Nov 2018, Julien Grall wrote:
Hi,
On 11/15/18 1:19 PM, Andrii Anisov wrote:
So I would prefer to stick with _t which is quite common within the p2m
code base so far.
I've found a similar code only in one place - p2m_get_e
flight 129966 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129966/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128925
test-amd64-i386-xl-qemut-win7-amd64 17
On Wed, 14 Nov 2018, Julien Grall wrote:
> On 14/11/2018 23:04, Stefano Stabellini wrote:
> > On Wed, 14 Nov 2018, Julien Grall wrote:
> >> Hi Mirela,
> >>
> >> On 14/11/2018 13:00, Mirela Simonovic wrote:
> >>>
> >>>
> >>> On 11/14/2018 11:52 AM, Julien Grall wrote:
> Hi Mirela,
>
>
On Thu, Nov 15, 2018 at 05:41:44PM +, Anthony PERARD wrote:
> On Thu, Nov 01, 2018 at 06:32:07PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Nov 01, 2018 at 04:57:18PM +, Ian Jackson wrote:
> > > Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support
> > > for qe
On Thu, 15 Nov 2018, Julien Grall wrote:
> Hi,
>
> On 11/15/18 1:19 PM, Andrii Anisov wrote:
> > > So I would prefer to stick with _t which is quite common within the p2m
> > > code base so far.
> >
> > I've found a similar code only in one place - p2m_get_entry()
> > function. And it is, at leas
Anthony PERARD writes ("[PATCH v6.2 05/11] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> Signed-off-by: Anthony PERARD
Thanks for the additional comments. I got thoroughly stuck in.
Overall the structure looks broadly right and my comments are
generally about details. As might be expected
On Wed, 14 Nov 2018, Julien Grall wrote:
> Hi,
>
> On 14/11/2018 22:18, Stefano Stabellini wrote:
> > On Wed, 14 Nov 2018, Julien Grall wrote:
> > @@ -1319,6 +1341,129 @@ static void gicv2_do_LPI(unsigned int lpi)
> > BUG();
> > }
> > +static void gicv2_alloc_contex
Hi Mirela,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
When Dom0 finalizes its suspend procedure the suspend of Xen is
triggered by calling system_suspend(). Dom0 finalizes the suspend from
its boot core (VCPU#0), which could be mapped to any physical CPU,
i.e. the system_suspend() function co
On 11/15/18 7:45 AM, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating a
On Thu, Nov 15, 2018 at 01:01:17PM +0100, David Hildenbrand wrote:
> Just saying that "I'm not the first to do it, don't hit me with a stick" :)
:-)
> Indeed. And we still have without makedumpfile. I think you are aware of
> this, but I'll explain it just for consistency: PG_hwpoison
No, I appr
On 11/15/18 7:34 PM, George Dunlap wrote:
>
>
>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>> wrote:
>>
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The reas
On Thu, Nov 01, 2018 at 06:32:07PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Nov 01, 2018 at 04:57:18PM +, Ian Jackson wrote:
> > Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support
> > for qemu-xen runnning in a Linux-based stubdomain."):
> > > 2. pv console
> >
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles logdirty
From: Christopher Clark
[modified for Xen 4.11 to add required: #include ]
Add zero-padding to #defined ACPI table strings that are copied.
Provides sufficient characters to satisfy the length required to
fully populate the destination and prevent array-bounds warnings.
Add BUILD_BUG_ON sizeof c
flight 130125 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 130122 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130122/
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 15.11.18 at 17:22, wrote:
> When platform timer initialisation fails due to missing interrupts, hardware
> tends to livelock without identifying the timer in use.
Have you observed this on non-flawed hardware? Is there
anything that needs fixing?
> Leave a trace around to help debugging.
When platform timer initialisation fails due to missing interrupts, hardware
tends to livelock without identifying the timer in use.
Leave a trace around to help debugging.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Brian Woods
---
xen/arch/x86/time
On 11/15/18 5:52 PM, George Dunlap wrote:
>
>
>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>> wrote:
>>
>> This patch is a pre-requisite for the one fixing VGA logdirty
>> freezes when using altp2m. It only concerns itself with the
>> ranges allocation / deallocation / initialization part. W
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
>
> Add logdirty_ranges allocator / deallocator helpers.
> p2m_init_logdirty() will not re-allocate if
> p2m->logdirty ranges has already been allocated.
>
> Move the rangeset deallocation call from p2m_teardown_hostp2m()
> to p2m_free_o
>>> On 15.11.18 at 16:48, wrote:
> On Thu, Nov 15, 2018 at 08:40:11AM -0700, Jan Beulich wrote:
>> >>> On 14.11.18 at 12:57, wrote:
>> > Bridges are not behind an IOMMU, and are already special cased and
>> > silently skipped in amd_iommu_add_device. Apply the same special
>> > casing when updati
On Thu, Nov 15, 2018 at 08:34:44AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_init.c
> > +++ b/xen/drivers/passthrough/amd/iommu_init.c
> > @@ -993,6 +993,16 @@ static void * __init allocate_ppr_log(struct amd_iommu
> > *iommu)
> >
>
flight 130120 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130120/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
>
> This patch is a pre-requisite for the one fixing VGA logdirty
> freezes when using altp2m. It only concerns itself with the
> ranges allocation / deallocation / initialization part. While
> touching the code, I've switched global_logd
On Thu, Nov 15, 2018 at 08:40:11AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, wrote:
> > Bridges are not behind an IOMMU, and are already special cased and
> > silently skipped in amd_iommu_add_device. Apply the same special
> > casing when updating page tables.
>
> But bridges also do
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/xen/gntdev.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index b0b0
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/xen/privcmd-buf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/xen/privcmd-buf.c b/drivers/xen/privcmd-buf.c
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_d
On 15/11/2018 13:52, Andrew Cooper wrote:
> All from code inspection
>
> Andrew Cooper (4):
> x86/vvmx: Drop unused CASE_{GET,SET}_REG() macros
> x86/vvmx: Correct the INVALID_PADDR checks for VMPTRLD/VMCLEAR
> x86/vvmx: Fixes to VMWRITE emulation
> x86/vvmx: Don't call vmsucceed() at the
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_ra
>>> On 14.11.18 at 12:57, wrote:
> Bridges are not behind an IOMMU, and are already special cased and
> silently skipped in amd_iommu_add_device. Apply the same special
> casing when updating page tables.
But bridges also don't issue I/O on their own if I'm not mistaken. So
what I'm missing here
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
vm_insert_ra
>>> On 14.11.18 at 12:57, wrote:
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -993,6 +993,16 @@ static void * __init allocate_ppr_log(struct amd_iommu
> *iommu)
>
> static int __init amd_iommu_init_one(struct amd_iommu *iommu)
> {
> +
On 15/11/2018 15:28, Sergey Dyasli wrote:
> On 15/11/2018 13:52, Andrew Cooper wrote:
>> This ends up corrupting L1's view of RFLAGS by setting ZF. The correct value
>> is established earlier in the function.
> vmsucceed() doesn't set any flags, only clears some. And in this function it's
> just r
On 15/11/2018 13:52, Andrew Cooper wrote:
> This ends up corrupting L1's view of RFLAGS by setting ZF. The correct value
> is established earlier in the function.
vmsucceed() doesn't set any flags, only clears some. And in this function it's
just redundant. ZF is set by VMfailValid. So I think th
At 05:51 -0700 on 15 Nov (1542261108), Jan Beulich wrote:
> Writes to such pages need to be handed to the emulator.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject
On 11/15/18 1:31 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
вт, 6 лист. 2018 о 21:16 Julien Grall пише:
In a follow-up patches, we will need to handle get_page_from_gfn
differently for DOMID_XEN. To keep the code simple move the current
content in a new separate helper p2m_get_page_from
On Thu, Nov 15, 2018 at 01:52:50PM +, Andrew Cooper wrote:
> This ends up corrupting L1's view of RFLAGS by setting ZF. The correct value
> is established earlier in the function.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
On 15/11/2018 14:30, Wei Liu wrote:
> Read from XEN_CONFIG_DIR/dom0-uuid. If it contains a valid UUID, set
> it for Dom0.
>
> Signed-off-by: Wei Liu
> ---
> v2:
> 1. add missing "goto out"
> 2. print file names more
> 3. also print errno in xc_interface_open error message
> 4. take care of short-
>>> On 15.11.18 at 15:23, wrote:
> On 09/11/2018 17:16, Andrew Cooper wrote:
>>
>>> However, one
>>> issue already might be that in order for bits in a (sub)leaf above
>>> (guest) limits to come out all clear, it is guest_cpuid() which cuts
>>> things off. Neither cpuid_featureset_to_policy() nor
Wei Liu writes ("[PATCH v2] xen: report PV capability in sysctl and use it in
toolstack"):
> 0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
> truth table for what `xl info` would report. In order to make the
> table work xen will need to report its PV capability.
Acked-by: Ian
Hi,
On 11/15/18 1:19 PM, Andrii Anisov wrote:
So I would prefer to stick with _t which is quite common within the p2m
code base so far.
I've found a similar code only in one place - p2m_get_entry()
function. And it is, at least, somehow commented there:
...
/* Allow t to be NULL */
t
On Thu, Nov 15, 2018 at 01:52:49PM +, Andrew Cooper wrote:
> * Don't assume that decode_vmx_inst() always returns X86EMUL_EXCEPTION.
> * The okay boolean is never written, making the else case dead.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
On Thu, Nov 15, 2018 at 01:52:48PM +, Andrew Cooper wrote:
> The referenced addresses also need checking against MAXPHYSADDR.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Sergey Dyasli
> CC: Jun Nakajima
On Thu, Nov 15, 2018 at 01:52:47PM +, Andrew Cooper wrote:
> These have been obsolete since c/s 053ae230 "x86/vvmx: Remove enum
> vmx_regs_enc".
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@li
On Thu, Nov 08, 2018 at 05:08:05PM +, Ian Jackson wrote:
> * Promise that we will set errno to ENOENT if the server is not
> yet set up.
> * Arrange that all ENOENT returns other than from the read of ring-ref
> are turned into EIO, logging when we do so.
>
> Signed-off-by: Ian Jackson
A
On Thu, Nov 08, 2018 at 05:07:57PM +, Ian Jackson wrote:
> Delete 11 entirely formulaic conditional calls to
> xtl_createlogger_stdiostream(stderr, XTL_PROGRESS, 0);
> and associated logger_tofree variables, error handling, etc.
>
> No overall functional change, although some memory allocati
On Thu, Nov 08, 2018 at 05:07:56PM +, Ian Jackson wrote:
> Previously xtl_log, xtl_logv and xtl_progress would all crash if
> passed logger=NULL. Have the use the default logger instead.
> This is more convenient.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
__
On 14/11/2018 18:17, Wei Liu wrote:
> If that's set, the stub is going to contain that UUID.
>
> No functional change.
>
> Signed-off-by: Wei Liu
> ---
> tools/helpers/init-dom-json.c| 5 -
> tools/helpers/init-dom-json.h| 3 ++-
> tools/helpers/init-xenstore-domain.c | 2 +-
>
On Thu, Nov 15, 2018 at 02:28:15PM +, Andrew Cooper wrote:
> On 14/11/2018 18:17, Wei Liu wrote:
> > This file gets installed to the host system.
> >
> > This patch cleans it up: 1. remove things that don't exist anymore; 2.
> > change xm to xl; 3. fix xen-devel list address; 4. add things that
Read from XEN_CONFIG_DIR/dom0-uuid. If it contains a valid UUID, set
it for Dom0.
Signed-off-by: Wei Liu
---
v2:
1. add missing "goto out"
2. print file names more
3. also print errno in xc_interface_open error message
4. take care of short-read
---
tools/examples/Makefile | 1 +
tools/ex
flight 130112 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130112/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
On 14/11/2018 18:17, Wei Liu wrote:
> This file gets installed to the host system.
>
> This patch cleans it up: 1. remove things that don't exist anymore; 2.
> change xm to xl; 3. fix xen-devel list address; 4. add things that are
> missing.
>
> Signed-off-by: Wei Liu
Is this file actually worth
flight 130110 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130110/
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 09/11/2018 17:16, Andrew Cooper wrote:
>
>> However, one
>> issue already might be that in order for bits in a (sub)leaf above
>> (guest) limits to come out all clear, it is guest_cpuid() which cuts
>> things off. Neither cpuid_featureset_to_policy() nor its inverse
>> nor sanitise_featureset()
On Thu, Nov 15, 2018 at 01:11:02PM +0100, Michal Hocko wrote:
> I am not familiar with kexec to judge this particular patch but we
> cannot simply define any range for these pages (same as for hwpoison
> ones) because they can be almost anywhere in the available memory range.
> Then there can be co
On 15/11/2018 12:45, Jan Beulich wrote:
> 1: __hvm_copy() should not write to p2m_ioreq_server pages
> 2: hvm_map_guest_frame_rw() should respect p2m_ioreq_server
> 3: emulate_gva_to_mfn() should respect p2m_ioreq_server
Acked-by: Andrew Cooper
___
Xen
All from code inspection
Andrew Cooper (4):
x86/vvmx: Drop unused CASE_{GET,SET}_REG() macros
x86/vvmx: Correct the INVALID_PADDR checks for VMPTRLD/VMCLEAR
x86/vvmx: Fixes to VMWRITE emulation
x86/vvmx: Don't call vmsucceed() at the end of virtual_vmexit()
xen/arch/x86/hvm/vmx/vvmx.c |
* Don't assume that decode_vmx_inst() always returns X86EMUL_EXCEPTION.
* The okay boolean is never written, making the else case dead.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/
This ends up corrupting L1's view of RFLAGS by setting ZF. The correct value
is established earlier in the function.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vvmx.c | 1 -
1
These have been obsolete since c/s 053ae230 "x86/vvmx: Remove enum
vmx_regs_enc".
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vvmx.c | 5 -
1 file changed, 5 deletions(-)
di
The referenced addresses also need checking against MAXPHYSADDR.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/vmx/vvmx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
dif
Reviewed-by: Andrii Anisov
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Reviewed-by: Andrii Anisov
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15/11/2018 13:35, Wei Liu wrote:
> On Thu, Nov 15, 2018 at 11:20:37AM +, Wei Liu wrote:
>> On Thu, Nov 15, 2018 at 10:45:52AM +, Edwin Török wrote:
>>> On 14/11/2018 18:17, Wei Liu wrote:
Read from XEN_CONFIG_DIR/dom0-uuid. If it contains a valid UUID, set
it for Dom0.
>>>
Sorry,
Not "comparingly complex", but "equally complex". ;)
Sincerely,
Andrii Anisov.
чт, 15 лист. 2018 о 15:31 Andrii Anisov пише:
>
> Hello Julien,
>
> вт, 6 лист. 2018 о 21:16 Julien Grall пише:
> >
> > In a follow-up patches, we will need to handle get_page_from_gfn
> > differently for DOMI
On Thu, Nov 15, 2018 at 11:20:37AM +, Wei Liu wrote:
> On Thu, Nov 15, 2018 at 10:45:52AM +, Edwin Török wrote:
> > On 14/11/2018 18:17, Wei Liu wrote:
> > > Read from XEN_CONFIG_DIR/dom0-uuid. If it contains a valid UUID, set
> > > it for Dom0.
> > >
> > > Signed-off-by: Wei Liu
> >
> >
1 - 100 of 158 matches
Mail list logo
