> From: Roger Pau Monne
> Sent: Saturday, March 21, 2020 3:08 AM
>
> Current code in nvmx_update_apicv set the guest interrupt status field
> but doesn't update the exit bitmap, which can cause issues of lost
> interrupts on the L1 hypervisor if vmx_intr_assist gets
> short-circuited by nvmx_intr
> From: Roger Pau Monne
> Sent: Saturday, March 21, 2020 3:08 AM
>
> The current usage of nvmx_update_apicv is not clear: it is deeply
> intertwined with the Ack interrupt on exit VMEXIT control.
>
> The code in nvmx_update_apicv should update the SVI (in service interrupt)
> field of the guest
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbits.xen.org/qemu-xen
> From: Roger Pau Monné
> Sent: Monday, March 23, 2020 10:49 PM
>
> On Mon, Mar 23, 2020 at 09:09:59AM +0100, Jan Beulich wrote:
> > On 20.03.2020 20:07, Roger Pau Monne wrote:
> > > This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
> > >
> > > The commit is wrong, as the whole point
Currently the xl dmesg output on Hygon platforms will be
"(XEN) CPU0: AMD Fam18h machine check reporting enabled",
which is misleading as AMD does not have family 18h (Hygon
negotiated with AMD to confirm that only Hygon has family 18h).
To correct this, add Hygon machine check type and vendor str
According to chapter "Appendix B Layout of VMCB" in the new version
(v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
GUEST_INTERRUPT_MASK.
In current xen codes, it use whole u64 interrupt_shadow to setup
interrupt shadow, which will misuse other bit in VMCB offset 68h
as part of in
flight 148901 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
148666
Tests which are
flight 148890 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
133580
Regressions
On Mon, Mar 23, 2020 at 04:35:12PM +0100, Roger Pau Monné wrote:
> On Mon, Jan 06, 2020 at 05:03:40PM +0100, Marek Marczykowski-Górecki wrote:
> > Alternatively, toolstack could wait for the actual backend node to be
> > removed (by the driver domain), and then cleanup the parent directory (if
> >
On Tue, Mar 17, 2020 at 11:01:43PM +, YOUNG, MICHAEL A. wrote:
> pygrub in xen-4.13.0 with python 3.8.2 fails with the error
>
> Traceback (most recent call last):
> File "/usr/libexec/xen/bin/pygrub", line 21, in
> import xen.lowlevel.xc
> SystemError: bad call flags
>
> This patch fi
flight 148921 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148921/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-fiano12 hosts-allocate starved n/a
examine-huxelrebe12 hosts-allocate
flight 148879 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148879/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 14486
On 3/23/20 12:15 PM, Yan Yankovskyi wrote:
> Make event channel functions pass event channel port using
> evtchn_port_t type. It eliminates signed <-> unsigned conversion.
>
> Signed-off-by: Yan Yankovskyi
If the difference is only the whitespace fix then
Reviewed-by: Boris Ostrovsky
and I
Hi!
I was going through how Xen support PCIe IOMMU ACS and
all I could find is this:
https://github.com/xen-project/xen/blob/master/xen/drivers/passthrough/pci.c#L608
which looks to me as an attempt of enabling ACS opportunistically,
but still proceeding forward even if it fails.
Am I missin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git
Hi all,
I'm currently working on a Qubes OS server version (example architecture can
been seen at
https://raw.githubusercontent.com/fepitre/qubes-mgmt-salt-qubes-server/devel-140320-extra/qubes-server.png).
I'm using this configuration since several months on Qubes R4.0 (xen-4.8) and
recently
flight 148873 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148873/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like
148611
test-amd64-amd64-xl-qemuu-win7-am
The following series implements VM forking for Intel HVM guests to allow for
the fast creation of identical VMs without the assosciated high startup costs
of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The fork operation is implemented a
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
doc
Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then creating a new fork would be. Measurements show abou
VM forking is the process of creating a domain with an empty memory space and a
parent domain specified from which to populate the memory when necessary. For
the new domain to be functional the VM state is copied over as part of the fork
operation (HVM params, hap allocation, etc).
Signed-off-by:
The function usbback_packet_complete() currently takes a USBPacket*,
which must be a pointer to the packet field within a struct
usbback_req; the function uses container_of() to get the struct
usbback_req* given the USBPacket*.
This is unnecessarily confusing (and in particular it confuses the
Cov
Sorry to come into this late.
Andrew Cooper writes ("Re: [Xen-devel] [PATCH] tools/xenstore: don't close
connection in xs_talkv()"):
> On 23/03/2020 15:44, Andrew Cooper wrote:
> > On 23/03/2020 14:29, Juergen Gross wrote:
> >> In case of some errors xs_talkv() will close the connection to
> >> X
Make event channel functions pass event channel port using
evtchn_port_t type. It eliminates signed <-> unsigned conversion.
Signed-off-by: Yan Yankovskyi
---
drivers/xen/events/events_2l.c| 16 ++---
drivers/xen/events/events_base.c | 93 ++-
drivers/xen/eve
On 23/03/2020 15:44, Andrew Cooper wrote:
> On 23/03/2020 14:29, Juergen Gross wrote:
>> In case of some errors xs_talkv() will close the connection to
>> Xenstore. This is annoying as it is not clear to the caller in which
>> error case the connection is still available.
>>
>> Drop that implicit c
On 23/03/2020 14:29, Juergen Gross wrote:
> In case of some errors xs_talkv() will close the connection to
> Xenstore. This is annoying as it is not clear to the caller in which
> error case the connection is still available.
>
> Drop that implicit closing to make the interface behave in a sane and
On Mon, Jan 06, 2020 at 05:03:40PM +0100, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 06, 2020 at 03:40:22PM +, Ian Jackson wrote:
> > Adding Roger to the CC.
> >
> > Marek Marczykowski-Górecki writes ("Re: [PATCH] libxl: create backend/
> > xenstore dir for driver domains"):
> > > On Mon
On Mon, Mar 23, 2020 at 01:50:54PM +, Qais Yousef wrote:
> The new functions use device_{online,offline}() which are userspace
> safe.
>
> This is in preparation to move cpu_{up, down} kernel users to use
> a safer interface that is not racy with userspace.
>
> Suggested-by: "Paul E. McKenney
On Thu, Mar 19, 2020 at 04:24:12PM +, Anthony PERARD wrote:
> On Tue, Mar 17, 2020 at 06:05:24PM +, Anthony PERARD wrote:
> > On Thu, Feb 27, 2020 at 12:05:04PM +0100, Roger Pau Monné wrote:
> > > On Wed, Feb 26, 2020 at 11:33:47AM +, Anthony PERARD wrote:
> > > > +ifneq ($(CONFIG_CC_IS
On Fri, Mar 20, 2020 at 04:09:18AM +0100, Marek Marczykowski-Górecki wrote:
> xen_pcibk_get_interrupt_type() assumes INTERRUPT_TYPE_NONE being 0
> (initialize ret to 0 and return as INTERRUPT_TYPE_NONE).
> Fix the definition to make INTERRUPT_TYPE_NONE really 0, and also shift
> other values to not
I also did a full review of all callers, and only the xen driver
forgot to call drm_dev_put in the failure path. Fix that up too.
v2: I noticed that xen has a drm_driver.release hook, and uses
drm_dev_alloc(). We need to remove the kfree from
xen_drm_drv_release().
bochs also has a release hook,
On Mon, Mar 23, 2020 at 09:09:59AM +0100, Jan Beulich wrote:
> On 20.03.2020 20:07, Roger Pau Monne wrote:
> > This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
> >
> > The commit is wrong, as the whole point of nvmx_update_apicv is to
> > update the guest interrupt status field when t
This allows a PVH/HVM domain to use unpopulated memory ranges to map
foreign memory or grants, and is required for a PVH dom0 to function
properly.
Signed-off-by: Roger Pau Monné
---
ts-kernel-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index c9762
In case of some errors xs_talkv() will close the connection to
Xenstore. This is annoying as it is not clear to the caller in which
error case the connection is still available.
Drop that implicit closing to make the interface behave in a sane and
predictable way.
Signed-off-by: Juergen Gross
--
On 23.03.2020 14:26, Andrew Cooper wrote:
> On 23/03/2020 12:33, Jan Beulich wrote:
>> On 23.03.2020 11:17, Andrew Cooper wrote:
>>> --- a/xen/include/asm-x86/microcode.h
>>> +++ b/xen/include/asm-x86/microcode.h
>>> @@ -7,8 +7,13 @@
>>> #include
>>>
>>> struct cpu_signature {
>>> +/* CPU
The added function measure_performance allows to measure the run time
of a function, by computing the average time it takes to call that
function a given number of retries. The measured total time is returned
in nano seconds. Furthermore, the value is printed via printk in a
fixed format, to allow
Dear all,
I added a benchmark category to XTF, and added functions to measure time in the
guest. Finally, I added a first micro benchmark that measures the time to call a
specified hypercall, and print the average time the hypercall takes.
The added category should be useful to implement further
To measure how long a certain interaction takes, we need time
primitives. This commit introduces these primitives, so that
future tests can use the gettimeofday function to retrieve the
current time.
Signed-off-by: Paul Semel
Signed-off-by: Norbert Manthey
---
build/files.mk | 1 +
commo
A first simple test is to call a hypercall in a tight loop. To measure
implementation aspects of the hypervisor, we picked a hypercall that
is not implemented and hence results in a no-op, namely the hypercall
mmuext_op with the command MMUEXT_MARK_SUPER.
The test calibrates the execution time for
As XTF allows to write tests that interact with the hypervisor, we would like
to use this capability to implement micro benchmarks, so that we can measure
the performance impact of modifications to the hypervisor.
This change introduces a category benchmark, which can be used as
container for test
The new functions use device_{online,offline}() which are userspace
safe.
This is in preparation to move cpu_{up, down} kernel users to use
a safer interface that is not racy with userspace.
Suggested-by: "Paul E. McKenney"
Signed-off-by: Qais Yousef
CC: Thomas Gleixner
CC: "Paul E. McKenney"
=
Changes in v4
=
* Split arm and arm64 patches so that the change to use reboot_cpu goes
into its own separate patch (Russell)
* Collected new Acked-by
* Rebased on top of v5.6-rc6
* Trimmed the CC list on the cover letter as lists
The core device API performs extra housekeeping bits that are missing
from directly calling cpu_up/down.
See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
serialization during LPM") for an example description of what might go
wrong.
This also prepares to make cpu_up/down a private
branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-t
On 3/23/20 1:33 AM, Yan Yankovskyi wrote:
> Make event channel functions pass event channel port using
> evtchn_port_t type. It eliminates signed <-> unsigned conversion.
>
> Signed-off-by: Yan Yankovskyi
Reviewed-by: Boris Ostrovsky
>
> @@ -1275,7 +1276,7 @@ void rebind_evtchn_irq(int ev
On 23/03/2020 12:33, Jan Beulich wrote:
> On 23.03.2020 11:17, Andrew Cooper wrote:
>> ... and struct cpu_signature for good measure.
>>
>> No comment is passed on the suitability of the behaviour...
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pau Mon
flight 148887 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On 23.03.2020 11:17, Andrew Cooper wrote:
> ... and struct cpu_signature for good measure.
>
> No comment is passed on the suitability of the behaviour...
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> ---
> xen/arch/x86/cpu/microcode/private.h
Hi,
On 23/03/2020 12:11, Hongyan Xia wrote:
On Sun, 2020-03-22 at 16:14 +, jul...@xen.org wrote:
From: Julien Grall
The first parameter of {s,g}et_gpfn_from_mfn() is an MFN, so it can
be
switched to use the typesafe.
At the same time, replace gpfn with pfn in the helpers as they all
deal
On Sun, 2020-03-22 at 16:14 +, jul...@xen.org wrote:
> From: Julien Grall
>
> The first parameter of {s,g}et_gpfn_from_mfn() is an MFN, so it can
> be
> switched to use the typesafe.
>
> At the same time, replace gpfn with pfn in the helpers as they all
> deal
> with PFN and also turn the ma
For one, subleaves within the respective union shouldn't live in
separate sub-structures. And then x86_cpuid_policy_fill_native() should,
as it did originally, iterate over all subleaves here as well as over
all main leaves. Switch to using a "<= MIN()"-based approach similar to
that used in x86_cp
On Tue, Mar 17, 2020 at 11:01:43PM +, YOUNG, MICHAEL A. wrote:
> pygrub in xen-4.13.0 with python 3.8.2 fails with the error
>
> Traceback (most recent call last):
> File "/usr/libexec/xen/bin/pygrub", line 21, in
> import xen.lowlevel.xc
> SystemError: bad call flags
>
> This patch fi
> -Original Message-
> From: Julien Grall
> Sent: 23 March 2020 11:34
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini
> ; Wei Liu
> Subject: Re: [PA
> -Original Message-
> From: Julien Grall
> Sent: 23 March 2020 10:47
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich
> ; Konrad Rzeszutek Wilk ; Stefano
> Stabellini
> ; Wei Liu
> Subject: Re: [PA
Hi Paul,
On 18/03/2020 11:11, Paul Durrant wrote:
From: Paul Durrant
This patch details proposes extra migration data and xenstore protocol
extensions to support non-cooperative live migration of guests.
NOTE: doc/misc/xenstore.txt is also amened to replace the term
NIT: s/amened/amended/
On Sat, Mar 07, 2020 at 09:06:08AM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:25:44PM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put in the failure path. Fix that up too.
>
> So ~40 callers - phew..
>
>
On Mon, 2020-03-23 at 09:34 +, Julien Grall wrote:
> For liveupdate, we will need a way to initialize a page but mark it as
> already inuse (i.e in the same state as they would be if allocated
> normally).
I am unconvinced of the veracity of this claim.
We don't want to turn specific detail
Hi,
On 18/03/2020 11:11, Paul Durrant wrote:
From: Paul Durrant
It has become apparent to some large cloud providers that the current
model of cooperative migration of guests under Xen is not usable as it
relies on software running inside the guest, which is likely beyond the
provider's contro
On Mon, 2020-03-23 at 08:49 +, Paul Durrant wrote:
> Ok, so deferring the call to free_heap_pages() (and consequently
> init_heap_pages()) is safe to defer until the guest is torn down? (Or
> is this only safe if the page is being assigned to the initial
> domain?)
It's intended to be safe in
Hi Juergen & Jan,
On 26/02/2020 12:47, Juergen Gross wrote:
diff --git a/docs/misc/hypfs-paths.pandoc b/docs/misc/hypfs-paths.pandoc
index 1faebcccbc..b4a5b6086e 100644
--- a/docs/misc/hypfs-paths.pandoc
+++ b/docs/misc/hypfs-paths.pandoc
@@ -152,3 +152,12 @@ The major version of Xen.
/bu
flight 148851 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Tests which a
Hi Paul,
On 23/03/2020 08:37, Paul Durrant wrote:
-Original Message-
From: jul...@xen.org
Sent: 22 March 2020 16:14
To: xen-devel@lists.xenproject.org
Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
;
Volodymyr Babchuk ; Andrew Cooper
; George
Dunlap ; Ian Jackson ; Jan
Beulich
microcode_sanity_check()'s callers actually call it with a mixture of
microcode_intel and microcode_header_intel pointers, which is fragile.
Rework it to take struct microcode_intel *, which in turn requires
microcode_update_match()'s type to be altered.
No functional change - compiled binary is
Rewrite the size checks in a way which which doesn't depend on Xen being
compiled as 64bit.
Introduce a check missing from the old code, that total_size is a multiple of
1024 bytes, and drop unnecessarily defines/macros/structures.
No practical change in behaviour.
Signed-off-by: Andrew Cooper
cpu_request_microcode() needs to scan its container and duplicate one blob,
but the get_next_ucode_from_buffer() helper duplicates every blob in turn.
Furthermore, the length checking is only safe from overflow in 64bit builds.
Delete get_next_ucode_from_buffer() and alter the purpose of the saved
Implement a new get_ext_sigtable() helper to abstract the logic for
identifying whether an extended signature table exists. As part of this,
rename microcode_intel.bits to data and change its type so it can be usefully
used in combination with the datasize header field.
Also, replace the sigmatch
Currently, we allocate an 8 byte struct microcode_patch to point at a
separately allocated struct microcode_intel. This is wasteful.
Fold struct microcode_header_intel and microcode_intel into microcode_patch to
simplify the code and remove a level of indirection.
The two semantic changes are in
This focuses on the Intel ucode driver, removing the gratuitous memory
allocations and indirection, as well as minor fixes in other areas of the
logic.
It depends on both the Part 1 and 2 series, and hopefully better demonstrates
why making struct microcode_patch opaque is a sensible move forward.
... and struct cpu_signature for good measure.
No comment is passed on the suitability of the behaviour...
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/private.h | 46
xen/include/asm-x86/
Every caller actually passes a struct microcode_header_intel. Implement the
helpers with proper types, and leave a comment explaining the Pentium Pro/II
behaviour with empty {data,total}size fields.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger P
flight 148853 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148853/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
148666
Tests which did
From: Wei Liu
Signed-off-by: Wei Liu
Reviewed-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 71c84ac593..6a0ffe088b 100644
--- a/xen/arch/x86/x86_64/mm.
From: Wei Liu
Signed-off-by: Wei Liu
Reviewed-by: Hongyan Xia
---
xen/arch/x86/pv/shim.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index ed2ece8a8a..1229d5ffb3 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arc
From: Wei Liu
Fetch lYe by mapping and unmapping lXe instead of using the direct map,
which is now done via the new lYe_from_lXe() helpers.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 12 ++--
xen/include/asm-x86/page.h | 18 ++
2
From: Hongyan Xia
This small series is basically just rewriting functions using the new
API to map and unmap PTEs. Each patch is independent.
Apart from mapping and unmapping page tables, no other functional change
intended.
Wei Liu (5):
x86/shim: map and unmap page tables in replace_va_mappi
From: Wei Liu
Signed-off-by: Wei Liu
Reviewed-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index b7ce833ffc..a440dac25e 100644
--- a/xen/arch/x86/x86_64/m
From: Wei Liu
Signed-off-by: Wei Liu
Reviewed-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 2680173fab..71c84ac593 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/x
Hi David,
On 20/03/2020 15:17, David Woodhouse wrote:
On Fri, 2020-03-20 at 13:33 +, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Behalf Of David
Woodhouse
Sent: 19 March 2020 21:22
To: xen-devel@lists.xenproject.org
Cc: Stefano Stabellini ; Julien Grall ; Wei
Liu ;
> -Original Message-
> > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > > index 62507ca651..5f0581c072 100644
> > > --- a/xen/arch/x86/mm.c
> > > +++ b/xen/arch/x86/mm.c
> > > @@ -491,7 +491,8 @@ void share_xen_page_with_guest(struct page_info
> > > *page, struct domain *d,
> > >
On 20.03.2020 22:24, Andrew Cooper wrote:
> Two minor bugfixes, and two minor cleanups with minor benefits to other code
> as well.
>
> There is no dependency on the remaining pieces of the Part 1 series.
>
> Andrew Cooper (4):
> x86/ucode/amd: Fix assertion in compare_patch()
> x86/ucode: Fi
On 21.03.2020 23:19, Julien Grall wrote:
> On Fri, 20 Mar 2020 at 21:26, Andrew Cooper wrote:
>> --- a/xen/include/xen/xmalloc.h
>> +++ b/xen/include/xen/xmalloc.h
>> @@ -51,6 +51,17 @@
>> #define xmalloc_bytes(_bytes) _xmalloc(_bytes, SMP_CACHE_BYTES)
>> #define xzalloc_bytes(_bytes) _xzalloc(_
> -Original Message-
> From: jul...@xen.org
> Sent: 22 March 2020 16:14
> To: xen-devel@lists.xenproject.org
> Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini
> ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich
> ; Wei Liu ; Roger Pau Monné
>
On 20.03.2020 22:24, Andrew Cooper wrote:
> @@ -259,15 +260,14 @@ static int apply_microcode(const struct microcode_patch
> *patch)
> /* check current patch id and patch's id for match */
> if ( hw_err || (rev != hdr->patch_id) )
> {
> -printk(KERN_ERR "microcode: CPU%d upda
On 23.03.2020 01:09, Marek Marczykowski-Górecki wrote:
> But there is more: additionally, in most (all?) cases after resume I've got
> soft lockup in Linux dom0 in smp_call_function_single() - see below. It
> didn't happened before and the only change was Xen 4.13 -> master.
Unless the Linux side
On 20.03.2020 20:07, Roger Pau Monne wrote:
> This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
>
> The commit is wrong, as the whole point of nvmx_update_apicv is to
> update the guest interrupt status field when the Ack on exit VMEXIT
> control feature is enabled.
>
> Signed-off-by:
On 20.03.2020 17:48, Andrew Cooper wrote:
> On 20/03/2020 16:16, Jan Beulich wrote:
>> On 20.03.2020 17:10, Andrew Cooper wrote:
>>> On 20/03/2020 15:15, Jan Beulich wrote:
On 20.03.2020 15:50, Andrew Cooper wrote:
> On 20/03/2020 13:51, Jan Beulich wrote:
>> On 19.03.2020 16:26, Andre
On 23.03.2020 06:35, Yan Yankovskyi wrote:
> struct evtchn_set_priority uses uint32_t type for event channel port.
> Replace the type with evtchn_port_t. Such change is also done in Linux.
>
> Signed-off-by: Yan Yankovskyi
Reviewed-by: Jan Beulich
As a general remark, the order of changes woul
87 matches
Mail list logo
