On 7/15/19 8:48 PM, Juergen Gross wrote:
On 15.07.19 21:31, Sarah Newman wrote:
On 7/15/19 11:57 AM, Foerster, Leonard wrote:
...
A key cornerstone for Live-update is guest transparent live migration
...
-> for live migration: domid is a problem in this case
-> randomize and pray
On 15.07.19 19:39, Andrew Cooper wrote:
On 15/07/2019 18:28, Andy Lutomirski wrote:
On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
Juergen Gross writes:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used
On 15.07.19 17:44, Boris Ostrovsky wrote:
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 084de77a109e..d42737f31304 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o
On 15.07.19 21:31, Sarah Newman wrote:
On 7/15/19 11:57 AM, Foerster, Leonard wrote:
...
A key cornerstone for Live-update is guest transparent live migration
...
-> for live migration: domid is a problem in this case
-> randomize and pray does not work on smaller fleets
flight 139014 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 138977
flight 139010 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139010/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 138915
flight 139011 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139011/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf eebc135ffb210c6da7133145ba9e5423cafc13d4
baseline version:
ovmf
flight 139016 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139016/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 163feb2e45cd088e65da1ff395dc3293065a4603
baseline version:
freebsd
flight 139003 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 133580
flight 139004 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
On 7/15/19 11:57 AM, Foerster, Leonard wrote:
...
A key cornerstone for Live-update is guest transparent live migration
...
-> for live migration: domid is a problem in this case
-> randomize and pray does not work on smaller fleets
-> this is not a
Hi Julien,
Julien Grall writes:
> At the moment, the user should save x30/lr if it cares about it.
>
> Follow-up patches will introduce more use of putn in place where lr
> should be preserved.
>
> Furthermore, any user of putn should also move the value to register x0
> if it was stored in a
Some numpty (me) forgot to organise a scribe for the session, so these
notes are from memory. As a result, all aspects are up for argumen^W
debate.
We started by discussing Core-aware scheduling, and covering the point
that while in principle it makes an attackers life easier, it doesn't
make a
Hi Viktor,
On 20/06/2019 11:38, Viktor Mitin wrote:
Functions make_timer_node and make_timer_domU_node are quite similar.
The only difference between Dom0 and DomU timer DT node
is the timer interrupts used. All the rest code should be the same.
This is a bit confusing to read. First you say
On Mon, 2019-07-15 at 14:59 +0100, George Dunlap wrote:
> Looking through the notes, it seems like the first part of this
> discussion, re hypervisor upgrade / downgrade & libraries, was partly
> covered in the distro session, in which Debian's Xen version co-
> install
> was discussed and found
On Mon, 2019-07-15 at 14:52 +, Jan Beulich wrote:
> On 15.07.2019 16:42, George Dunlap wrote:
> > On 7/15/19 3:23 PM, Jan Beulich wrote:
> > > On 15.07.2019 16:11, George Dunlap wrote:
> > > > There was a long discussion about security patches, with the
> > > > general
> > > > proposal being
On 15.07.19 19:28, Andy Lutomirski wrote:
On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
Juergen Gross writes:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86
On 15/07/2019 18:28, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>> Juergen Gross writes:
>>
>>> The long term plan has been to replace Xen PV guests by PVH. The first
>>> victim of that plan are now 32-bit PV guests, as those are used only
>>> rather seldom these
On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>
> Juergen Gross writes:
>
> > The long term plan has been to replace Xen PV guests by PVH. The first
> > victim of that plan are now 32-bit PV guests, as those are used only
> > rather seldom these days. Xen on x86 requires 64-bit support and
On 15/07/2019 18:26, Julien Grall wrote:
> Hi,
>
> On 10/07/2019 05:57, Viktor Mitin wrote:
>> Update ARM code coverage warning about testing gcov on arm
>>
>> Signed-off-by: Viktor Mitin
>
> Acked-by: Julien Grall
Docs parts Acked-by: Andrew Cooper
Hi,
On 10/07/2019 05:57, Viktor Mitin wrote:
Update ARM code coverage warning about testing gcov on arm
Signed-off-by: Viktor Mitin
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi,
On 15/07/2019 10:17, Paul Durrant wrote:
The _PGC_allocated flag is set on a page when it is assigned to a domain
along with an initial reference count of at least 1. To clear this
'allocation' reference it is necessary to test-and-clear _PGC_allocated and
then only drop the reference if
%cr8 is an alias of APIC_TASKPRI, which is handled by
lapic_{suspend,resume}() with the rest of the Local APIC state. Saving
and restoring the TPR state in isolation is not a clever idea.
Drop it all.
While editing wakeup_prot.S, trim its include list to just the headers
which are used, which
Juergen Gross writes:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporting PVH officially since version 2.04
On Mon, Jul 01, 2019 at 08:05:24AM +0200, Sam Ravnborg wrote:
> Hi Oleksandr
>
> > > --- a/drivers/gpu/drm/xen/xen_drm_front.h
> > > +++ b/drivers/gpu/drm/xen/xen_drm_front.h
> > > @@ -11,13 +11,19 @@
> > > #ifndef __XEN_DRM_FRONT_H_
> > > #define __XEN_DRM_FRONT_H_
> > > -#include
> > >
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> If a pCPU has been/is being offlined, we don't want it to be neither
> assigned to any pCPU, nor in the wait list.
I take it the first `pCPU` should be `vCPU`?
Also, English grammar agreement is funny: `neither` needs to agree with
`nor`, but the two
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 July 2019 16:46
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2 4/4] iommu / pci: re-implement
> XEN_DOMCTL_get_device_group...
>
> On Mon, Jul 15, 2019 at 01:37:10PM
On 8/25/18 1:21 AM, Dario Faggioli wrote:
> vcpu_deassign() has only one caller: _vcpu_remove().
> Let's consolidate the two functions into one.
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
___
On Mon, Jul 15, 2019 at 01:37:10PM +0100, Paul Durrant wrote:
> ... using the new iommu_group infrastructure.
>
> Because 'sibling' devices are now members of the same iommu_group,
> implement the domctl by looking up the iommu_group of the pdev with the
> matching SBDF and then finding all the
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index 084de77a109e..d42737f31304 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -OBJECT_FILES_NON_STANDARD_xen-asm_$(BITS).o := y
>
> -Original Message-
> From: Roger Pau Monne
> Sent: 15 July 2019 16:35
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Wei Liu ;
> Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew
> Cooper ; Ian Jackson ; Tim
> (Xen.org) ;
> Julien Grall ; Jan Beulich
On Mon, Jul 15, 2019 at 01:37:09PM +0100, Paul Durrant wrote:
> Some devices may share a single PCIe initiator id, e.g. if they are actually
> legacy PCI devices behind a bridge, and hence DMA from such devices will
> be subject to the same address translation in the IOMMU. Hence these devices
>
On Mon, Jul 15, 2019 at 01:37:08PM +0100, Paul Durrant wrote:
> ...and use it for setup_hwdom_pci_devices() and dump_pci_devices().
>
> The unlock/process-pending-softirqs/lock sequence that was in
> _setup_hwdom_pci_devices() is now done in the generic iterator function,
> which does mean it is
On 7/11/19 8:02 AM, Zhenzhong Duan wrote:
> PVH guest needs PV extentions to work, so "nopv" parameter should be
> ignored for PVH but not for HVM guest.
>
> If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
> we know it's PVH guest and ignore "nopv" parameter directly.
>
>
On Tue, Jan 10, 2017 at 4:14 PM Juergen Gross wrote:
>
> Today xenstored tries to open a tdb data base file on disk when it is
> started. As this is problematic in most cases the scripts used to start
> xenstored ensure xenstored won't find such a file in order to start
> with an empty xenstore.
Nothing guarantees that the original frame's stack pointer points at
readable memory. Avoid a (likely nested) crash by attaching exception
recovery to the read (making it a single read at the same time). Don't
even invoke _show_trace() in case of a non-readable top slot.
Signed-off-by: Jan
Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
often for relatively simple leaf functions. (To give a specific example,
the case I've run into this with is _pci_hide_device() and gcc 8.
Interestingly the even more simple neighboring iommu_has_feature() does
get a frame
On 15/07/2019 15:19, Jan Beulich wrote:
> On 15.07.2019 15:49, Andrew Cooper wrote:
>> On 15/07/2019 11:35, Jan Beulich wrote:
>>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>>
>>> dom0_build.c:344:24: error: use of logical '&&' with constant operand
>>> [-Werror,-Wconstant-logical-operand]
1: guard top-of-stack reads
2: widen condition for logging top-of-stack
The issue patch 2 fixes (a curious lack of an intermediate call stack
entry) was observed in practice; patch 1 is a result of me just looking
at the code.
Jan
___
Xen-devel mailing
On 15.07.2019 16:42, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>>
On 15.07.2019 16:44, Tamas K Lengyel wrote:
> On Mon, Jul 15, 2019 at 8:13 AM Jan Beulich wrote:
>>
>> On 15.07.2019 15:41, Tamas K Lengyel wrote:
>>> On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error:
On 7/15/19 3:42 PM, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>> Interesting.
On Mon, Jul 15, 2019 at 8:13 AM Jan Beulich wrote:
>
> On 15.07.2019 15:41, Tamas K Lengyel wrote:
> > On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
> >>
> >> With non-empty CONFIG_DOM0_MEM clang5 produces
> >>
> >> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> >>
On 7/15/19 3:23 PM, Jan Beulich wrote:
> On 15.07.2019 16:11, George Dunlap wrote:
>> There was a long discussion about security patches, with the general
>> proposal being that we should cut a point release for every security issue.
>
> Interesting. Looks like in politics that until a decision
flight 138996 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
This is faster than using the software implementation, and the insn is
available on all half-way recent hardware. Therefore convert
generic_hweight() to out-of-line functions (without affecting Arm)
and use alternatives patching to replace the function calls.
Note that the approach doesn#t work
On Mon, Jul 15, 2019 at 01:37:07PM +0100, Paul Durrant wrote:
> It's not vendor specific so it doesn't really belong there.
>
> Scanning the PCI topology also really doesn't have much to do with IOMMU
> initialization. It doesn't depend on there even being an IOMMU. This patch
> moves to the call
On Mon, Jul 15, 2019 at 12:50:29PM +0100, Andrew Cooper wrote:
> On 15/07/2019 12:46, Roger Pau Monné wrote:
> >> +;
> >> +; Jump to the main routine of the pre-SEC code
> >> +; skiping the 16-bit part of the routine and
> >> +; into the 32-bit flat mode part
> >> +;
> >> +
On 15.07.2019 16:11, George Dunlap wrote:
> There was a long discussion about security patches, with the general
> proposal being that we should cut a point release for every security issue.
Interesting. Looks like in politics that until a decision fits people
they keep re-raising the point. Iirc
On Thu, Jul 04, 2019 at 03:42:07PM +0100, Anthony PERARD wrote:
> ACPI Timer does not work in a PVH guest, but local APIC works on both
This is not accurate. It's not that the ACPI timer doesn't work, it's
just that it's not present. The PM_TMR_BLK should be set to 0 to
indicate the lack of PM
On 15.07.2019 15:49, Andrew Cooper wrote:
> On 15/07/2019 11:35, Jan Beulich wrote:
>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>
>> dom0_build.c:344:24: error: use of logical '&&' with constant operand
>> [-Werror,-Wconstant-logical-operand]
>> if ( !dom0_mem_set &&
On Thu, Jul 04, 2019 at 03:42:22PM +0100, Anthony PERARD wrote:
> When running as a Xen PVH guest, there is no CMOS to read the memory
> size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
> works without CMOS by reading the e820 table.
>
> Rework XenPublishRamRegions for PVH,
On 15.07.2019 15:41, Tamas K Lengyel wrote:
> On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
>>
>> With non-empty CONFIG_DOM0_MEM clang5 produces
>>
>> dom0_build.c:344:24: error: use of logical '&&' with constant operand
>> [-Werror,-Wconstant-logical-operand]
>> if ( !dom0_mem_set &&
Much of this covered things discussed elsewhere:
* Allowing multiple versions of the tools to be installed at the same time
* Getting rid of external builds
There was a long discussion about security patches, with the general
proposal being that we should cut a point release for every security
On 05/07/2019 14:56, Dario Faggioli wrote:
> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
>> 1) This crash is quite likely to happen:
>>
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
>> that CPU2 is stuck!
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.226293]
Looking through the notes, it seems like the first part of this
discussion, re hypervisor upgrade / downgrade & libraries, was partly
covered in the distro session, in which Debian's Xen version co-install
was discussed and found useful even if we had a hypervisor , Ian Jackson
agreed to post
On 15/07/2019 11:35, Jan Beulich wrote:
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
> ^
On Mon, Jul 15, 2019 at 4:36 AM Jan Beulich wrote:
>
> With non-empty CONFIG_DOM0_MEM clang5 produces
>
> dom0_build.c:344:24: error: use of logical '&&' with constant operand
> [-Werror,-Wconstant-logical-operand]
> if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
> ^
Below are the raw notes. General agreements seem to be:
* Removing external builds from xen build system is an advantage for the
main users (developers, distros / packagers)
* Out-of-tree build is useful for lots of circumstances; symlink trick
used to work around its lack causes lots of
... using the new iommu_group infrastructure.
Because 'sibling' devices are now members of the same iommu_group,
implement the domctl by looking up the iommu_group of the pdev with the
matching SBDF and then finding all the assigned pdevs that are in the
group.
Signed-off-by: Paul Durrant
---
...and use it for setup_hwdom_pci_devices() and dump_pci_devices().
The unlock/process-pending-softirqs/lock sequence that was in
_setup_hwdom_pci_devices() is now done in the generic iterator function,
which does mean it is also done (unnecessarily) in the case of
dump_pci_devices(), since
Some devices may share a single PCIe initiator id, e.g. if they are actually
legacy PCI devices behind a bridge, and hence DMA from such devices will
be subject to the same address translation in the IOMMU. Hence these devices
should be treated as a unit for the purposes of assignment. There are
It's not vendor specific so it doesn't really belong there.
Scanning the PCI topology also really doesn't have much to do with IOMMU
initialization. It doesn't depend on there even being an IOMMU. This patch
moves to the call to the beginning of iommu_hardware_setup() but only
places it there
On 15.07.19 14:32, Peter Zijlstra wrote:
On Mon, Jul 15, 2019 at 01:37:37PM +0200, Juergen Gross wrote:
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires
This series is a mixture of tidying and some preparatory work for grouping
PCI devices for the purposes of assignment.
Paul Durrant (4):
iommu / x86: move call to scan_pci_devices() out of vendor code
pci: add all-device iterator function...
iommu: introduce iommu_groups
iommu / pci:
On Mon, Jul 15, 2019 at 01:37:37PM +0200, Juergen Gross wrote:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
On 15.07.2019 13:09, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 15 July 2019 11:44
>>
>> Well, the problem is that I don't feel well adjusting what a native
>> English speaking person has written.
>
> Ok. How about...
>
> "This patch adds a helper function, put_page_alloc_ref(), to
On 15/07/2019 13:01, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Signed-off-by: George Dunlap
---
v2:
- Put in alphabetical order
- Replace spaces with tabs
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
CC: Konrad Wilk
CC: Stefano Stabellini
CC: Julien Grall
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
On 7/10/19 3:51 AM, Jan Beulich wrote:
> On 09.07.2019 22:13, George Dunlap wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -343,6 +343,11 @@ M: Marek Marczykowski-Górecki
>>
>> S: Supported
>> F: tools/python
>>
>> +GOLANG BINDINGS
>> +M: George Dunlap
>> +S:
On 15/07/2019 12:46, Roger Pau Monné wrote:
>> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>> b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>> new file mode 100644
>> index 00..2a17fed52f
>> --- /dev/null
>> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm
>> @@ -0,0 +1,49 @@
On Thu, Jul 04, 2019 at 03:42:04PM +0100, Anthony PERARD wrote:
> Add a new entry point for Xen PVH that enter directly in 32bits.
>
> Information on the expected state of the machine when this entry point
> is used can be found at:
> https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
>
Xen is requiring 64-bit machines today. There is no need to carry the
burden of 32-bit PV guest support in the kernel any longer, as new
guests can be either HVM or PVH, or they can use a 64 bit kernel.
Remove the 32-bit Xen PV support from the kernel.
Signed-off-by: Juergen Gross
---
The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
Remove 32-bit specific parts.
Signed-off-by: Juergen Gross
---
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 +
arch/x86/include/asm/paravirt.h | 105
The long term plan has been to replace Xen PV guests by PVH. The first
victim of that plan are now 32-bit PV guests, as those are used only
rather seldom these days. Xen on x86 requires 64-bit support and with
Grub2 now supporting PVH officially since version 2.04 there is no
need to keep 32-bit
Hi,
On 12/07/2019 19:32, Hunyue Yau z wrote:
On Friday, July 12, 2019 16:13:32 Julien Grall wrote:
Hi,
On 7/11/19 7:29 PM, Hunyue Yau wrote:
[This mail incorporates comments raised on IRC. I have made some of this
mHi,ore verbose to provide context to people that haven't seen the IRC
flight 138992 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138992/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-build fail in 138772 REGR. vs. 132889
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2019 11:44
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; VolodymyrBabchuk ;
> Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk
> ;
On 15.07.2019 11:50, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 15 July 2019 10:24
>>
>> On 15.07.2019 11:17, Paul Durrant wrote:
>>> The _PGC_allocated flag is set on a page when it is assigned to a domain
>>> along with an initial reference count of at least 1. To clear this
>>>
On Mon, Jul 08, 2019 at 11:47:11AM -0700, Chaitanya Kulkarni wrote:
> This patch updates the vbd_sz() macro with newly introduced helper
> function to read the nr_sects from block device's hd_parts with the
> help of part_nr_sects_read().
>
> Signed-off-by: Chaitanya Kulkarni
Acked-by: Roger
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:24: error: use of logical '&&' with constant operand
[-Werror,-Wconstant-logical-operand]
if ( !dom0_mem_set && CONFIG_DOM0_MEM[0] )
^ ~~
dom0_build.c:344:24: note: use '&' for a bitwise
On Fri, Jul 05, 2019 at 04:06:06PM +, Jan Beulich wrote:
> >>> On 05.06.19 at 08:51, wrote:
> > First and foremost make timer_softirq_action() avoid growing the heap
> > if its new size can't be stored without truncation. 64k entries is a
> > lot, and I don't think we're at risk of actually
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2019 10:24
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> VolodymyrBabchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ;
On Fri, Jul 12, 2019 at 10:41 PM Ian Jackson wrote:
>
> Here are the photos I took of the flipchart:
> https://xenbits.xen.org/people/iwj/2019/summit-ci-branch-workshop/
FYI, I can see the directory, but when I click on the individual
images, I get this:
You don't have permission to access
On 15.07.2019 11:17, Paul Durrant wrote:
> The _PGC_allocated flag is set on a page when it is assigned to a domain
> along with an initial reference count of at least 1. To clear this
> 'allocation' reference it is necessary to test-and-clear _PGC_allocated and
> then only drop the reference if
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2019 10:18
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Volodymyr Babchuk ;
> Stefano Stabellini
> ; xen-devel@lists.xenproject.org; Konrad Rzeszutek
> Wilk
> ;
On 15.07.2019 10:45, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 10 July 2019 23:53
>>
>> On 10.07.2019 18:17, Paul Durrant wrote:
>>> @@ -418,13 +417,7 @@ static void hvm_free_ioreq_mfn(struct hvm_ioreq_server
>>> *s, bool buf)
>>>unmap_domain_page_global(iorp->va);
>>>
The _PGC_allocated flag is set on a page when it is assigned to a domain
along with an initial reference count of at least 1. To clear this
'allocation' reference it is necessary to test-and-clear _PGC_allocated and
then only drop the reference if the test-and-clear succeeds. This is open-
coded
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then below panic
triggered:
[0.772876]
On 15/07/2019 07:54, Jan Beulich wrote:
> On 15.07.2019 07:05, Zhenzhong Duan wrote:
>> On 2019/7/12 22:06, Andrew Cooper wrote:
>>> On 11/07/2019 03:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap
>>> On 27.05.19 at 11:25, wrote:
On 13.03.19 at 13:39, wrote:
> > While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
> > expensive (but still needed only for the toggle_guest_mode() path), the
> > effect of the latter on the exit-to-guest path is not insignificant.
> >
On 03.07.2019 13:36, Jan Beulich wrote:
> The write-discard property of the type can't be represented in IOMMU
> page table entries. Make sure the respective checks / tracking can't
> race, by utilizing the domain lock. The other sides of the sharing/
> paging/log-dirty exclusion checks should
On 03.07.2019 13:29, Jan Beulich wrote:
On 27.05.19 at 11:36, wrote:
> On 12.04.19 at 13:41, wrote:
>> On 11.04.19 at 21:06, wrote:
On 11/04/2019 13:45, Jan Beulich wrote:
> When disabling SMT at runtime, secondary threads should no longer be
> candidates for bringing
On 12.07.2019 04:28, Jan Beulich wrote:
> On 11.07.2019 19:13, Tamas K Lengyel wrote:
>>> @@ -629,6 +697,14 @@ static void *hvmemul_map_linear_addr(
>>>
>>>ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
>>>}
>>> +
>>> +if ( curr->arch.vm_event &&
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2019 13:00
> To: xen-devel@lists.xenproject.org; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Roger
> Pau Monne
> ; Paul Durrant
> Subject: [PATCH] x86/hvm: make hvmemul_virtual_to_linear()'s reps parameter
>
On 05.07.2019 18:06, Jan Beulich wrote:
On 05.06.19 at 08:51, wrote:
>> First and foremost make timer_softirq_action() avoid growing the heap
>> if its new size can't be stored without truncation. 64k entries is a
>> lot, and I don't think we're at risk of actually running into the issue,
>>
On 01.07.2019 13:59, Jan Beulich wrote:
> A majority of callers wants just a single iteration handled. Allow to
> express this by passing in a NULL pointer, instead of setting up a local
> variable just to hold the "1" to pass in here.
>
> Signed-off-by: Jan Beulich
> ---
> Note that this
> -Original Message-
> From: Jan Beulich
> Sent: 10 July 2019 23:53
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Julien Grall ;
> Andrew Cooper
> ; Roger Pau Monne ;
> Volodymyr Babchuk
> ; George Dunlap ; Ian
> Jackson
> ; Stefano Stabellini ; Konrad
> Rzeszutek Wilk
> ;
flight 138998 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138998/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70565e64227dfa254d8a0703dd60dc74bd8b5e6e
baseline version:
ovmf
1 - 100 of 103 matches
Mail list logo
