On 29.03.23 09:20, Juergen Gross wrote:
Hello Juergen
> On 28.03.23 17:47, Oleksandr Tyshchenko wrote:
>>
>>
>> On 28.03.23 11:46, Juergen Gross wrote:
>>
>> Hello Juergen
>>
>>> scsiback_free_translation_entry() shouldn't be called under spinlock,
>>> as it can sleep.
>>>
>>> This requires to
First of all these were inverted: "bridge=" caused the port coordinates
to be established, while "port=" controlled the bridge coordinates. And
then the error messages being identical also wasn't helpful. While
correcting this also move both case blocks close together.
Fixes: 97fd49a7e074 ("ns1655
At 12:37 +0200 on 28 Mar (1680007032), Jan Beulich wrote:
> On 27.03.2023 17:39, Tim Deegan wrote:
> > At 10:33 +0100 on 22 Mar (1679481226), Jan Beulich wrote:
> >> There's no need for an indirect call here, as the mode is invariant
> >> throughout the entire paging-locked region. All it takes to
On 28.03.23 15:32, Jan Beulich wrote:
On 28.03.2023 15:12, Juergen Gross wrote:
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers
On 28.03.23 17:47, Oleksandr Tyshchenko wrote:
On 28.03.23 11:46, Juergen Gross wrote:
Hello Juergen
scsiback_free_translation_entry() shouldn't be called under spinlock,
as it can sleep.
This requires to split removing a translation entry from the v2p list
from actually calling kref_put()
flight 180043 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-vhd 21 guest-start/debian.repeatfail like 179993
test-amd64-amd64-xl-qemuu-win7-amd6
flight 180040 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180040/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail like
179969
test-amd64-amd64-xl-qemut-win7
flight 180044 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180044/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5eb3d1bcc16fb7dfd0c972bf71278e2c85dfc1ff
baseline version:
ovmf 07e17188df9042d6a6af9
flight 180038 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair25 guest-start/debian fail REGR. vs. 178042
test-amd64-amd64-fr
On Tue, Mar 28, 2023 at 9:17 AM Jason Andryuk wrote:
>
> On Tue, Mar 28, 2023 at 9:04 AM Marek Marczykowski-Górecki
> wrote:
> >
> > On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> > > On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
> > > > Some firmware/devices are found to
flight 180042 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180042/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 07e17188df9042d6a6af96f21b0fb7bc5595ec07
baseline version:
ovmf e4b3fd905a170b185dcea
On 28/03/2023 5:01 pm, Jan Beulich wrote:
> On 28.03.2023 17:12, Andrew Cooper wrote:
>> On 28/03/2023 3:19 pm, Jan Beulich wrote:
>>> On 27.03.2023 21:41, Andrew Cooper wrote:
Right now, the boot flow depends on the second pass over
bootstrap_map()/find_cpio_data() altering ucode_blob.da
On 28.03.2023 16:57, Roger Pau Monné wrote:
> On Wed, Jun 15, 2022 at 11:58:46AM +0200, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/x86_emulate/private.h
>> @@ -0,0 +1,531 @@
>> +/**
>> + * private.h - interfa
On 28.03.2023 17:12, Andrew Cooper wrote:
> On 28/03/2023 3:19 pm, Jan Beulich wrote:
>> On 27.03.2023 21:41, Andrew Cooper wrote:
>>> Right now, the boot flow depends on the second pass over
>>> bootstrap_map()/find_cpio_data() altering ucode_blob.data to use the
>>> directmap
>>> alias of the CP
On 28.03.2023 17:11, Andrew Cooper wrote:
> On 28/03/2023 3:06 pm, Jan Beulich wrote:
>> On 27.03.2023 21:41, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/microcode/core.c
>>> +++ b/xen/arch/x86/cpu/microcode/core.c
>>> @@ -868,8 +835,37 @@ int __init early_microcode_init(unsigned long
>>> *mod
On 28.03.2023 17:07, Andrew Cooper wrote:
> On 28/03/2023 2:51 pm, Jan Beulich wrote:
>> On 27.03.2023 21:41, Andrew Cooper wrote:
>>> It is not valid to retain a bootstrap_map() across returning back to
>>> __start_xen(), but various pointers get stashed across calls.
>> It's error prone, yes, but
On 28.03.23 11:46, Juergen Gross wrote:
Hello Juergen
> scsiback_free_translation_entry() shouldn't be called under spinlock,
> as it can sleep.
>
> This requires to split removing a translation entry from the v2p list
> from actually calling kref_put() for the entry.
>
> Reported-by: Dan Car
Hi,
On 28/03/2023 16:34, Jan Beulich wrote:
On 27.03.2023 19:17, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/include/asm/config.h
+++ b/xen/arch/riscv/include/asm/config.h
@@ -39,12 +39,25 @@
name:
#endif
-#define XEN_VIRT_START _AT(UL, 0x8020)
+#define ADDRESS_SPACE_END (_AC(-1
On 28.03.2023 17:08, Jason Andryuk wrote:
> On Tue, Mar 28, 2023 at 9:54 AM Jan Beulich wrote:
>>
>> On 28.03.2023 15:43, Jason Andryuk wrote:
>>> On Tue, Mar 28, 2023 at 9:35 AM Jan Beulich wrote:
On 28.03.2023 15:32, Jason Andryuk wrote:
> On Tue, Mar 28, 2023 at 9:28 AM Roger Pau
On Thu, 2023-03-16 at 10:52 +0100, Jan Beulich wrote:
> On 15.03.2023 18:21, Oleksii Kurochko wrote:
> > The following changes were made:
> > * Make GENERIC_BUG_FRAME mandatory for X86
> > * Update asm/bug.h using generic implementation in
> > * Update do_invalid_op using generic do_bug_frame()
>
On 27.03.2023 19:17, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -39,12 +39,25 @@
>name:
> #endif
>
> -#define XEN_VIRT_START _AT(UL, 0x8020)
> +#define ADDRESS_SPACE_END (_AC(-1, UL))
> +#define SZ_1G
On Tue, Mar 28, 2023 at 04:49:36PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 04:04:47PM +0200, Roger Pau Monné wrote:
> > On Mon, Mar 27, 2023 at 12:09:15PM +0200, Marek Marczykowski-Górecki wrote:
> > > In some cases, only few registers on a page needs to be write-protecte
On 28/03/2023 3:19 pm, Jan Beulich wrote:
> On 27.03.2023 21:41, Andrew Cooper wrote:
>> Right now, the boot flow depends on the second pass over
>> bootstrap_map()/find_cpio_data() altering ucode_blob.data to use the
>> directmap
>> alias of the CPIO module, where previously it caches the early b
On 28/03/2023 3:06 pm, Jan Beulich wrote:
> On 27.03.2023 21:41, Andrew Cooper wrote:
>> Begin to address this by folding early_update_cache() into it's single
>> caller,
>> rearranging the exit path to always invalidate the mapping.
> ... this looks to lack editing after copy-and-paste from the e
On Tue, Mar 28, 2023 at 9:54 AM Jan Beulich wrote:
>
> On 28.03.2023 15:43, Jason Andryuk wrote:
> > On Tue, Mar 28, 2023 at 9:35 AM Jan Beulich wrote:
> >>
> >> On 28.03.2023 15:32, Jason Andryuk wrote:
> >>> On Tue, Mar 28, 2023 at 9:28 AM Roger Pau Monné
> >>> wrote:
> On Tue, Mar 28, 2
On 28/03/2023 2:51 pm, Jan Beulich wrote:
> On 27.03.2023 21:41, Andrew Cooper wrote:
>> It is not valid to retain a bootstrap_map() across returning back to
>> __start_xen(), but various pointers get stashed across calls.
> It's error prone, yes, but "not valid" isn't really true imo: As long as
>
flight 180041 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180041/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, Jun 15, 2022 at 11:58:46AM +0200, Jan Beulich wrote:
> --- /dev/null
> +++ b/xen/arch/x86/x86_emulate/private.h
> @@ -0,0 +1,531 @@
> +/**
> + * private.h - interface between x86_emulate.c and its helpers
> + *
> +
On Tue, Mar 28, 2023 at 04:04:47PM +0200, Roger Pau Monné wrote:
> On Mon, Mar 27, 2023 at 12:09:15PM +0200, Marek Marczykowski-Górecki wrote:
> > In some cases, only few registers on a page needs to be write-protected.
> > Examples include USB3 console (64 bytes worth of registers) or MSI-X's
> >
On 28.03.2023 16:19, Roger Pau Monné wrote:
> On Wed, Jun 15, 2022 at 11:57:54AM +0200, Jan Beulich wrote:
>> ... of the huge monolithic source file. The series is largely code
>> movement and hence has the intention of not incurring any functional
>> change.
>
> I take the intention is to make co
Today when finalizing a transaction the number of node quota is checked
to not being exceeded after the transaction. This check is always done,
even if the transaction is being performed by a privileged connection,
or if there were no nodes created in the transaction.
Correct that by checking quot
On 28.03.2023 15:57, Andrew Cooper wrote:
> On 24/03/2023 7:38 am, Jan Beulich wrote:
>> On 23.03.2023 19:18, Andrew Cooper wrote:
>>> On 22/03/2023 9:35 am, Jan Beulich wrote:
Emulation related functions are involved in HVM handling only, and in
some cases they even invoke such checks af
There is a part of a comment in create_node() which should have been
deleted when modifying the related coding.
Fixes: 1cd3cc7ea27c ("tools/xenstore: create_node: Don't defer work to undo any
changes on failure")
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
---
V2:
- add Fixes: tag (J
On 27.03.2023 21:41, Andrew Cooper wrote:
> These both incorrectly cache bootstrap_map()'d pointers across returns back to
> __start_xen(). This is never valid, and such pointers may fault, or point to
> something unrelated.
As before - unless bootstrap_map(NULL) was (carefully) not called in
bet
On Wed, Jun 15, 2022 at 11:57:54AM +0200, Jan Beulich wrote:
> ... of the huge monolithic source file. The series is largely code
> movement and hence has the intention of not incurring any functional
> change.
I take the intention is to make code simpler and easier to follow by
splitting it up in
On 27.03.2023 21:41, Andrew Cooper wrote:
> When microcode_scan_module() is used, it's used twice.
>
> The caching of the bootstrap_map() pointer in ucode_blob.data is buggy for
> multiple reasons and is going to be removed.
As before I'm not convinced of "buggy".
> Right now, the boot flow depe
On 27.03.2023 21:41, Andrew Cooper wrote:
> It is not valid to retain a bootstrap_map() across returning back to
> __start_xen(), but various pointers get stashed across calls.
Same comment here, and ...
> Begin to address this by folding early_update_cache() into it's single caller,
> rearrangin
On Mon, Mar 27, 2023 at 12:09:15PM +0200, Marek Marczykowski-Górecki wrote:
> In some cases, only few registers on a page needs to be write-protected.
> Examples include USB3 console (64 bytes worth of registers) or MSI-X's
> PBA table (which doesn't need to span the whole table either).
> Current
On 24/03/2023 7:38 am, Jan Beulich wrote:
> On 23.03.2023 19:18, Andrew Cooper wrote:
>> On 22/03/2023 9:35 am, Jan Beulich wrote:
>>> Emulation related functions are involved in HVM handling only, and in
>>> some cases they even invoke such checks after having already done things
>>> which are val
On 28.03.2023 15:52, Paolo Abeni wrote:
> On Tue, 2023-03-28 at 15:10 +0200, Juergen Gross wrote:
>> The fix for XSA-423 introduced a bug which resulted in loss of network
>> connection in some configurations.
>>
>> The first patch is fixing the issue, while the second one is removing
>> a test whi
On 28.03.2023 15:43, Jason Andryuk wrote:
> On Tue, Mar 28, 2023 at 9:35 AM Jan Beulich wrote:
>>
>> On 28.03.2023 15:32, Jason Andryuk wrote:
>>> On Tue, Mar 28, 2023 at 9:28 AM Roger Pau Monné
>>> wrote:
On Tue, Mar 28, 2023 at 03:23:56PM +0200, Jan Beulich wrote:
> On 28.03.2023 15:0
Hi,
On Tue, 2023-03-28 at 15:10 +0200, Juergen Gross wrote:
> The fix for XSA-423 introduced a bug which resulted in loss of network
> connection in some configurations.
>
> The first patch is fixing the issue, while the second one is removing
> a test which isn't needed. The third patch is makin
On 27.03.2023 21:41, Andrew Cooper wrote:
> It is not valid to retain a bootstrap_map() across returning back to
> __start_xen(), but various pointers get stashed across calls.
It's error prone, yes, but "not valid" isn't really true imo: As long as
nothing calls bootstrap_map(NULL) all mappings w
On Tue, Mar 28, 2023 at 9:35 AM Jan Beulich wrote:
>
> On 28.03.2023 15:32, Jason Andryuk wrote:
> > On Tue, Mar 28, 2023 at 9:28 AM Roger Pau Monné
> > wrote:
> >> On Tue, Mar 28, 2023 at 03:23:56PM +0200, Jan Beulich wrote:
> >>> On 28.03.2023 15:04, Marek Marczykowski-Górecki wrote:
> On
On 27.03.2023 21:41, Andrew Cooper wrote:
> This is imported from Linux, but the parameter being signed is dubious in the
> first place and we're not plausibly going to gain a use for the functionality.
> Linux has subsequently made it an optional parameter to avoid forcing callers
> to pass a stac
On 28.03.2023 15:32, Jason Andryuk wrote:
> On Tue, Mar 28, 2023 at 9:28 AM Roger Pau Monné wrote:
>> On Tue, Mar 28, 2023 at 03:23:56PM +0200, Jan Beulich wrote:
>>> On 28.03.2023 15:04, Marek Marczykowski-Górecki wrote:
On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> On 2
On 28.03.2023 15:12, Juergen Gross wrote:
> Issue the same error message in case an illegal page boundary crossing
> has been detected in both cases where this is tested.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Juergen Gross
> ---
> V2:
> - new patch
> ---
> drivers/net/xen-netback/netba
On Tue, Mar 28, 2023 at 9:28 AM Roger Pau Monné wrote:
>
> On Tue, Mar 28, 2023 at 03:23:56PM +0200, Jan Beulich wrote:
> > On 28.03.2023 15:04, Marek Marczykowski-Górecki wrote:
> > > On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> > >> On 25.03.2023 03:49, Marek Marczykowski-Górec
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni :
On Mon, 27 Mar 2023 10:36:44 +0200 you wrote:
> The fix for XSA-423 introduced a bug which resulted in loss of network
> connection in some configurations.
>
> The first patch is fixing the issue, while the second one is re
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni :
On Tue, 28 Mar 2023 15:10:44 +0200 you wrote:
> The fix for XSA-423 introduced a bug which resulted in loss of network
> connection in some configurations.
>
> The first patch is fixing the issue, while the second one is re
On Tue, Mar 28, 2023 at 03:23:56PM +0200, Jan Beulich wrote:
> On 28.03.2023 15:04, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> >> On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
> >>> Some firmware/devices are found to not reset MSI-X
flight 180036 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180036/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15 migrate-s
On 28.03.2023 15:04, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
>> On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
>>> Some firmware/devices are found to not reset MSI-X properly, leaving
>>> MASKALL set. Xen relies on initial state being
On Tue, Mar 28, 2023 at 03:03:17PM +0200, Jan Beulich wrote:
> On 28.03.2023 14:52, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 28, 2023 at 02:34:23PM +0200, Jan Beulich wrote:
> >> On 28.03.2023 14:05, Marek Marczykowski-Górecki wrote:
> >>> On Tue, Mar 28, 2023 at 01:28:44PM +0200, Roger Pa
On Tue, Mar 28, 2023 at 9:04 AM Marek Marczykowski-Górecki
wrote:
>
> On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> > On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
> > > Some firmware/devices are found to not reset MSI-X properly, leaving
> > > MASKALL set. Xen relies on
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers/net/xen-netback/netback.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(
The tests for the number of grant mapping or copy operations reaching
the array size of the operations buffer at the end of the main loop in
xenvif_tx_build_gops() isn't needed.
The loop can handle at maximum MAX_PENDING_REQS transfer requests, as
XEN_RING_NR_UNCONSUMED_REQUESTS() is taking unsent
Fix xenvif_get_requests() not to do grant copy operations across local
page boundaries. This requires to double the maximum number of copy
operations per queue, as each copy could now be split into 2.
Make sure that struct xenvif_tx_cb doesn't grow too large.
Cc: sta...@vger.kernel.org
Fixes: ad7
The fix for XSA-423 introduced a bug which resulted in loss of network
connection in some configurations.
The first patch is fixing the issue, while the second one is removing
a test which isn't needed. The third patch is making error messages
more uniform.
Changes in V2:
- add patch 3
- comment
On Tue, Mar 28, 2023 at 02:54:38PM +0200, Jan Beulich wrote:
> On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
> > Some firmware/devices are found to not reset MSI-X properly, leaving
> > MASKALL set. Xen relies on initial state being both disabled.
> > Especially, pci_reset_msix_state() ass
On 28.03.2023 14:52, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 02:34:23PM +0200, Jan Beulich wrote:
>> On 28.03.2023 14:05, Marek Marczykowski-Górecki wrote:
>>> On Tue, Mar 28, 2023 at 01:28:44PM +0200, Roger Pau Monné wrote:
On Sat, Mar 25, 2023 at 03:49:23AM +0100, Marek M
On 25.03.2023 03:49, Marek Marczykowski-Górecki wrote:
> Some firmware/devices are found to not reset MSI-X properly, leaving
> MASKALL set. Xen relies on initial state being both disabled.
> Especially, pci_reset_msix_state() assumes if MASKALL is set, it was Xen
> setting it due to msix->host_mas
On Tue, Mar 28, 2023 at 02:05:14PM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 01:28:44PM +0200, Roger Pau Monné wrote:
> > On Sat, Mar 25, 2023 at 03:49:23AM +0100, Marek Marczykowski-Górecki wrote:
> > > + address >= entry->gtable + entry->table_len )
> > > +
On Tue, Mar 28, 2023 at 02:34:23PM +0200, Jan Beulich wrote:
> On 28.03.2023 14:05, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 28, 2023 at 01:28:44PM +0200, Roger Pau Monné wrote:
> >> On Sat, Mar 25, 2023 at 03:49:23AM +0100, Marek Marczykowski-Górecki wrote:
> >>> +static bool cf_check msi
flight 180039 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180039/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e4b3fd905a170b185dcea11e2997cfe935fea208
baseline version:
ovmf 71fd87e98a3d68dffe2f3
On 28.03.2023 14:07, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 01:37:14PM +0200, Roger Pau Monné wrote:
>> On Sat, Mar 25, 2023 at 03:49:24AM +0100, Marek Marczykowski-Górecki wrote:
>>> --- a/xen/drivers/passthrough/msi.c
>>> +++ b/xen/drivers/passthrough/msi.c
>>> @@ -48,6 +48,1
On 28.03.2023 14:05, Marek Marczykowski-Górecki wrote:
> On Tue, Mar 28, 2023 at 01:28:44PM +0200, Roger Pau Monné wrote:
>> On Sat, Mar 25, 2023 at 03:49:23AM +0100, Marek Marczykowski-Górecki wrote:
>>> +static bool cf_check msixtbl_page_accept(
>>> +const struct hvm_io_handler *handler,
On 24.03.2023 13:17, Roger Pau Monne wrote:
> The handling of the MSI-X table accesses by Xen requires that any
> pages part of the MSI-X related tables are not mapped into the domain
> physmap. As a result, any device registers in the same pages as the
> start or the end of the MSIX or PBA tables
On Tue, Mar 28, 2023 at 01:37:14PM +0200, Roger Pau Monné wrote:
> On Sat, Mar 25, 2023 at 03:49:24AM +0100, Marek Marczykowski-Górecki wrote:
> > Some firmware/devices are found to not reset MSI-X properly, leaving
> > MASKALL set. Xen relies on initial state being both disabled.
>
> The 'both' i
On Tue, Mar 28, 2023 at 01:28:44PM +0200, Roger Pau Monné wrote:
> On Sat, Mar 25, 2023 at 03:49:23AM +0100, Marek Marczykowski-Górecki wrote:
> > Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
> > on the same page as MSI-X table. Device model (especially one in
> > stubdom
On 28.03.2023 12:27, Andrew Cooper wrote:
> On 27/03/2023 4:43 pm, Jan Beulich wrote:
>> On 24.03.2023 23:08, Andrew Cooper wrote:
>>> * For backporting, this patch depends on c/s e7f147bf4ac7 ("x86/crash: Drop
>>>manual hooking of exception_table[]") and c/s e7db635f4428 ("x86/pv-shim:
>>>
On 28.03.23 11:45, Juergen Gross wrote:
Hello Juergen
> pcistub_device_put() shouldn't be called under spinlock, as it can
> sleep.
>
> For this reason pcistub_device_get_pci_dev() needs to be modified:
> instead of always calling pcistub_device_get() just do the call of
> pcistub_device_get()
On Sat, Mar 25, 2023 at 03:49:24AM +0100, Marek Marczykowski-Górecki wrote:
> Some firmware/devices are found to not reset MSI-X properly, leaving
> MASKALL set. Xen relies on initial state being both disabled.
The 'both' in this sentence seems out of context, as you just mention
MASKALL in the pr
On Sat, Mar 25, 2023 at 03:49:23AM +0100, Marek Marczykowski-Górecki wrote:
> Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers
> on the same page as MSI-X table. Device model (especially one in
> stubdomain) cannot really handle those, as direct writes to that page is
> refus
Viresh Kumar writes:
> The current model of memory mapping at the back-end works fine where a
> standard call to mmap() (for the respective file descriptor) is enough
> before the front-end can start accessing the guest memory.
>
> There are other complex cases though where the back-end needs m
Viresh Kumar writes:
> The same layout is defined twice, once in "single memory region
> description" and then in "memory regions description".
>
> Separate out details of memory region from these two and reuse the same
> definition later on.
>
> While at it, also rename "memory regions descrip
On Tue, Mar 28, 2023 at 4:59 AM Jan Beulich wrote:
>
> On 21.03.2023 14:58, Dmitry Isaykin wrote:
> > Adds monitor support for I/O instructions.
> >
> > Signed-off-by: Dmitry Isaykin
> > Signed-off-by: Anton Belousov
>
> Acked-by: Jan Beulich
Acked-by: Tamas K Lengyel
On 28.03.23 12:34, Oleksandr Tyshchenko wrote:
On 28.03.23 12:39, Juergen Gross wrote:
Hello Juergen
bind_evtchn_to_irqhandler() shouldn't be called under spinlock, as it
can sleep.
This requires to move the calls of create_active() out of the locked
regions. This is no problem, as the wor
On 27/03/2023 3:00 pm, Anthony PERARD wrote:
> On Fri, Mar 24, 2023 at 08:14:04PM +, Andrew Cooper wrote:
>> Following Demi's work to use HTTPS everywhere, all users of GIT_HTTP have
>> been removed from the build system. Drop the configure knob.
>>
>> Signed-off-by: Andrew Cooper
> Do we nee
On Tue, Mar 28, 2023 at 10:59:37AM +0200, Jan Beulich wrote:
> On 21.03.2023 14:58, Dmitry Isaykin wrote:
> > Adds monitor support for I/O instructions.
> >
> > Signed-off-by: Dmitry Isaykin
> > Signed-off-by: Anton Belousov
>
> Acked-by: Jan Beulich
>
> On top of Kevin's R-b and besides Tama
flight 180035 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180035/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180024
test-amd64-i386-xl-qemuu-win7-amd64
On 27.03.2023 17:39, Tim Deegan wrote:
> At 10:33 +0100 on 22 Mar (1679481226), Jan Beulich wrote:
>> There's no need for an indirect call here, as the mode is invariant
>> throughout the entire paging-locked region. All it takes to avoid it is
>> to have a forward declaration of sh_update_cr3() in
On 28.03.23 12:39, Juergen Gross wrote:
Hello Juergen
bind_evtchn_to_irqhandler() shouldn't be called under spinlock, as it
can sleep.
This requires to move the calls of create_active() out of the locked
regions. This is no problem, as the worst which could happen would be
a spurious call
On 27/03/2023 4:43 pm, Jan Beulich wrote:
> On 24.03.2023 23:08, Andrew Cooper wrote:
>> While we've been diligent to ensure that the main text/data/rodata mappings
>> have suitable restrictions, their aliases via the directmap were left fully
>> read/write. Worse, we even had pieces of code makin
On 27.03.2023 12:59, Luca Fancellu wrote:
> --- a/xen/arch/arm/arm64/sve.c
> +++ b/xen/arch/arm/arm64/sve.c
> @@ -124,3 +124,15 @@ int __init sve_parse_dom0_param(const char *str_begin,
> const char *str_end)
> {
> return parse_integer("sve", str_begin, str_end, (int*)&opt_dom0_sve);
> }
>
On 27.03.2023 12:59, Luca Fancellu wrote:
> @@ -838,6 +838,18 @@ Controls for how dom0 is constructed on x86 systems.
>
> If using this option is necessary to fix an issue, please report a bug.
>
> +Enables features on dom0 on Arm systems.
> +
> +* The `sve` integer parameter enables Arm
On 27.03.2023 12:59, Luca Fancellu wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -59,6 +59,11 @@ static int __init parse_dom0_mem(const char *s)
> }
> custom_param("dom0_mem", parse_dom0_mem);
>
> +int __init parse_arch_dom0_param(const char *str_begin, con
bind_evtchn_to_irqhandler() shouldn't be called under spinlock, as it
can sleep.
This requires to move the calls of create_active() out of the locked
regions. This is no problem, as the worst which could happen would be
a spurious call of the interrupt handler, causing a spurious wake_up().
Repor
On 27.03.2023 12:59, Luca Fancellu wrote:
> @@ -43,8 +44,16 @@ register_t compute_max_zcr(void)
> }
>
> /* Takes a vector length in bits and returns the ZCR_ELx encoding */
> -register_t vl_to_zcr(uint16_t vl)
> +register_t vl_to_zcr(unsigned int vl)
> {
> ASSERT(vl > 0);
> return ((
On 28.03.2023 02:53, Stefano Stabellini wrote:
> On Mon, 27 Mar 2023, Julien Grall wrote:
>> From: Julien Grall
>>
>> It is easier to understand the license of a file when using SPDX.
>>
>> This is replacing the below pattern with the SPDX tag GPL-2.0-only
>> in xen/arch/x86/*.c:
>>
>> * This pro
On 21.03.2023 14:58, Dmitry Isaykin wrote:
> Adds monitor support for I/O instructions.
>
> Signed-off-by: Dmitry Isaykin
> Signed-off-by: Anton Belousov
Acked-by: Jan Beulich
On top of Kevin's R-b and besides Tamas'es (to-be-re-instated) ack this
also would preferably get one from Anthony.
scsiback_free_translation_entry() shouldn't be called under spinlock,
as it can sleep.
This requires to split removing a translation entry from the v2p list
from actually calling kref_put() for the entry.
Reported-by: Dan Carpenter
Link: https://lore.kernel.org/lkml/Y+JUIl64UDmdkboh@kadam/
Signe
pcistub_device_put() shouldn't be called under spinlock, as it can
sleep.
For this reason pcistub_device_get_pci_dev() needs to be modified:
instead of always calling pcistub_device_get() just do the call of
pcistub_device_get() only if it is really needed. This removes the
need to call pcistub_de
On 27.03.2023 18:10, Oleksii wrote:
> Hello Jan,
>
> On Thu, 2023-03-16 at 10:52 +0100, Jan Beulich wrote:
>> On 15.03.2023 18:21, Oleksii Kurochko wrote:
>>> The following changes were made:
>>> * Make GENERIC_BUG_FRAME mandatory for X86
>>> * Update asm/bug.h using generic implementation in
>>>
On 27.03.2023 18:22, Juergen Gross wrote:
> On 27.03.23 17:38, Jan Beulich wrote:
>> On 27.03.2023 12:07, Juergen Gross wrote:
>>> On 27.03.23 11:49, Jan Beulich wrote:
On 27.03.2023 10:36, Juergen Gross wrote:
> @@ -539,6 +553,13 @@ static int xenvif_tx_check_gop(struct xenvif_queue
flight 180037 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180037/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 71fd87e98a3d68dffe2f37ec1bdc61732c01597a
baseline version:
ovmf 144028626e0072c2c4fdf
With the change in previous patch, the initial 16 pages in the P2M
pool is not necessary anymore. Drop them for code simplification.
Also the call to p2m_teardown() from arch_domain_destroy() is not
necessary anymore since the movement of the P2M allocation out of
arch_domain_create(). Drop the co
Currently, the mapping of the GICv2 CPU interface is created in
arch_domain_create(). This causes some troubles in populating and
freeing of the domain P2M pages pool. For example, a default 16
P2M pages are required in p2m_init() to cope with the P2M mapping
of 8KB GICv2 CPU interface area, and th
In the follow-up patch from this series, the GICv2 CPU interface
mapping will be deferred until the first access in the stage-2
data abort trap handling code. Since the data abort trap handling
code is common for the current and the new vGIC implementation,
it is necessary to unify the variable nam
Currently, p2m for a domain will be teardown from two paths:
(1) The normal path when a domain is destroyed.
(2) The arch_domain_destroy() in the failure path of domain creation.
When tearing down p2m from (1), the part to clear and clean the root
is only needed to do once rather than for every ca
1 - 100 of 101 matches
Mail list logo
