On 07.08.2019 16:31, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -13,9 +13,9 @@
>
> static atomic_t spin_debug __read_mostly = ATOMIC_INIT(0);
>
> -static void check_lock(struct lock_debug *debug)
> +static void check_lock(union lock_debug *debug)
>
(I'm sorry if you receive duplicates of this, but I've got a reply
back from our mail system that several of the recipients did not
have their host names resolved correctly on the first attempt.)
On 07.08.2019 20:36, Oleksandr wrote:
>> There's one more thing for the re-alloc case though (besides
On Thu, Aug 8, 2019 at 9:45 AM Lars Kurth wrote:
> On the one hand, the testing relates to patches
> submission (mean patches should be tested before submission anyway),
> but on the other hand, testing details are not about the patches
> submission process. In any case, we do not
On 07.08.2019 16:31, Juergen Gross wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -53,6 +53,7 @@ config SPINLOCK_DEBUG
>
> config LOCK_PROFILE
> bool "Lock Profiling"
> + select SPINLOCK_DEBUG
> ---help---
> Lock profiling allows you to see how often lo
On 08.08.19 08:34, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -44,6 +44,13 @@ config COVERAGE
If unsure, say N here.
+config SPINLOCK_DEBUG
+ bool "Spinlock debugging"
+ default DEBUG
+ ---help---
+ Enable
On 07.08.2019 16:31, Juergen Gross wrote:
> @@ -463,31 +464,67 @@ int spinlock_profile_control(struct
> xen_sysctl_lockprof_op *pc)
> return rc;
> }
>
> -void _lock_profile_register_struct(
> -int32_t type, struct lock_profile_qhead *qhead, int32_t idx, char *name)
> +static struct
On 08/08/2019 08:07, Viktor Mitin wrote:
> On Thu, Aug 8, 2019 at 9:45 AM Lars Kurth wrote:
>
>> On the one hand, the testing relates to patches
>> submission (mean patches should be tested before submission anyway),
>> but on the other hand, testing details are not about the patches
>
On 08.08.2019 02:52, Marek Marczykowski-Górecki wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -315,8 +315,10 @@ static void __init efi_arch_handle_cmdline(CHAR16
>> *image_name,
>> name.s = "xen";
>> place_string(&mbi.cmdline, name.s);
>>
On 08.08.2019 09:23, Juergen Gross wrote:
> On 08.08.19 08:34, Jan Beulich wrote:
>> On 07.08.2019 16:31, Juergen Gross wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -44,6 +44,13 @@ config COVERAGE
>>> If unsure, say N here.
>>> +config SPINLOCK_DEBUG
>>> + bool "
On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -13,9 +13,9 @@
static atomic_t spin_debug __read_mostly = ATOMIC_INIT(0);
-static void check_lock(struct lock_debug *debug)
+static void check_lo
On 08.08.2019 09:51, Juergen Gross wrote:
> On 08.08.19 08:58, Jan Beulich wrote:
>> On 07.08.2019 16:31, Juergen Gross wrote:
>>> + unsigned short irq_safe:1;
>>> + unsigned short pad:2;
>>> + unsigned short cpu:12;
>>> + };
>>> };
>>
>> Do we have an implied assumption
On 8/7/19 7:22 PM, Stefano Stabellini wrote:
> Hi Dario, George,
>
> Dom0less with sched=null is broken on staging, it simply hangs soon
> after Xen is finished loading things. My impression is that vcpus are
> not actually started. I did a git bisection and it pointed to:
>
> commit d545f1d6c251
On 08.08.19 09:32, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
@@ -463,31 +464,67 @@ int spinlock_profile_control(struct
xen_sysctl_lockprof_op *pc)
return rc;
}
-void _lock_profile_register_struct(
-int32_t type, struct lock_profile_qhead *qhead, int32_t idx
On 08.08.2019 02:31, Marek Marczykowski-Górecki wrote:
> When booting Xen via xen.efi, there is /mapbs option to workaround
> certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
> map EfiBootServices{Code,Data}"). Add support for efi=mapbs on Xen
> cmdline for the same effect an
On 08.08.19 09:35, Jan Beulich wrote:
On 08.08.2019 09:23, Juergen Gross wrote:
On 08.08.19 08:34, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -44,6 +44,13 @@ config COVERAGE
If unsure, say N here.
+config SPINLOCK_DE
On 08.08.19 09:09, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -53,6 +53,7 @@ config SPINLOCK_DEBUG
config LOCK_PROFILE
bool "Lock Profiling"
+ select SPINLOCK_DEBUG
---help---
Lock profil
On 08/08/2019 05:50, Juergen Gross wrote:
> On 07.08.19 20:11, Andrew Cooper wrote:
>>
>>
>> Its not exactly the easiest to dump to follow.
>>
>> First of all - I don't see why the hold/block time are printed like
>> that. It
>> might be a holdover from the 32bit build, pre PRId64 support. They
On 08/08/2019 07:22, Jan Beulich wrote:
> On 07.08.2019 21:41, Andrew Cooper wrote:
>> --- /dev/null
>> +++ b/docs/glossary.rst
>> @@ -0,0 +1,37 @@
>> +Glossary
>> +
>> +
>> +.. Terms should appear in alphabetical order
>> +
>> +.. glossary::
>> +
>> + control domain
>> + A :term:`dom
On 07/08/2019 21:28, Oleksandr Tyshchenko wrote:
Hi, Julien.
Hi,
Sorry for the possible format issues.
> No, it is not disabled. But, ipmmu_irq() uses another mmu->lock. So, I
> think, there won't be a deadlock.
>
> Or I really missed something?
>
> If we worry
On 08.08.2019 10:43, Andrew Cooper wrote:
> On 08/08/2019 07:22, Jan Beulich wrote:
>> On 07.08.2019 21:41, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/docs/glossary.rst
>>> @@ -0,0 +1,37 @@
>>> +Glossary
>>> +
>>> +
>>> +.. Terms should appear in alphabetical order
>>> +
>>> +.. gloss
flight 139801 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139801/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 37b420014fdd0f6e1ea5aecd05f04ed0a33fa5b7
baseline version:
freebsd 17a1fc80d57
On Thu, Aug 08, 2019 at 02:44:42AM +, Zhang, Chen wrote:
> Ping...
> Any comments?
For your information, that patch have been pushed, see commit
174db28bb823e8c98c319fdbdc6d4cbe1050ba14 ;-)
Cheers,
--
Anthony PERARD
___
Xen-devel mailing list
Xen
On 08.08.2019 10:33, Andrew Cooper wrote:
> On 08/08/2019 05:50, Juergen Gross wrote:
>> On 07.08.19 20:11, Andrew Cooper wrote:
>>>
>>>
>>> Its not exactly the easiest to dump to follow.
>>>
>>> First of all - I don't see why the hold/block time are printed like
>>> that. It
>>> might be a holdo
Hi Jan,
On 08/08/2019 10:04, Jan Beulich wrote:
On 08.08.2019 10:43, Andrew Cooper wrote:
On 08/08/2019 07:22, Jan Beulich wrote:
On 07.08.2019 21:41, Andrew Cooper wrote:
--- /dev/null
+++ b/docs/glossary.rst
@@ -0,0 +1,37 @@
+Glossary
+
+
+.. Terms should appear in alphabetical orde
Hi Stefano,
On 07/08/2019 19:42, Stefano Stabellini wrote:
On Tue, 15 Jan 2019, Julien Grall wrote:
Hi Stefano,
On 1/3/19 7:07 PM, Stefano Stabellini wrote:
On Mon, 24 Dec 2018, Julien Grall wrote:
Hi,
On 12/5/18 5:28 PM, Stefano Stabellini wrote:
We don't have a clear way to know how many
On Thu, Aug 08, 2019 at 08:21:54AM +, Jan Beulich wrote:
> On 08.08.2019 02:31, Marek Marczykowski-Górecki wrote:
> > When booting Xen via xen.efi, there is /mapbs option to workaround
> > certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
> > map EfiBootServices{Code,Data}
Hi Stefano,
On 07/08/2019 22:01, Stefano Stabellini wrote:
On Tue, 15 Jan 2019, Julien Grall wrote:
On 1/3/19 10:07 PM, Stefano Stabellini wrote:
On Mon, 24 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 12/5/18 5:28 PM, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
doc
On 08.08.19 10:33, Andrew Cooper wrote:
On 08/08/2019 05:50, Juergen Gross wrote:
On 07.08.19 20:11, Andrew Cooper wrote:
Its not exactly the easiest to dump to follow.
First of all - I don't see why the hold/block time are printed like
that. It
might be a holdover from the 32bit build, pre
On 08/08/2019 01:31, Marek Marczykowski-Górecki wrote:
> When booting Xen via xen.efi, there is /mapbs option to workaround
> certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
> map EfiBootServices{Code,Data}"). Add support for efi=mapbs on Xen
> cmdline for the same effect and
On 08/08/2019 10:08, Jan Beulich wrote:
> On 08.08.2019 10:33, Andrew Cooper wrote:
>> On 08/08/2019 05:50, Juergen Gross wrote:
>>> On 07.08.19 20:11, Andrew Cooper wrote:
Its not exactly the easiest to dump to follow.
First of all - I don't see why the hold/block time are pri
flight 139792 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139792/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On Thu, Aug 08, 2019 at 09:43:01AM +0100, Andrew Cooper wrote:
> On 08/08/2019 07:22, Jan Beulich wrote:
> > On 07.08.2019 21:41, Andrew Cooper wrote:
> >> --- /dev/null
> >> +++ b/docs/glossary.rst
> >> @@ -0,0 +1,37 @@
> >> +Glossary
> >> +
> >> +
> >> +.. Terms should appear in alphabeti
flight 139794 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139794/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139379
test-amd64-amd64-xl-qemuu-
Hi,
Hi, Julien.
Sorry for the possible format issues.
> No, it is not disabled. But, ipmmu_irq() uses another
mmu->lock. So, I
> think, there won't be a deadlock.
>
> Or I really missed something?
>
> If we worry about ipmmu_tlb_invalidate() which is cal
On 08/08/2019 10:36, Juergen Gross wrote:
> On 08.08.19 10:33, Andrew Cooper wrote:
>> On 08/08/2019 05:50, Juergen Gross wrote:
>>> On 07.08.19 20:11, Andrew Cooper wrote:
Its not exactly the easiest to dump to follow.
First of all - I don't see why the hold/block time ar
On Wed, Aug 07, 2019 at 04:35:58PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:21PM +0100, Anthony PERARD wrote:
> > Check if there's a start of the day struct provided to PVH guest, save
> > the ACPI RSDP address for later.
> >
> > This patch import import arch-x86/hvm/start_inf
On 08/08/2019 08:51, Juergen Gross wrote:
On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
Do we have an implied assumption somewhere that unsigned short is
exactly 16 bits wide? I think "val" wants to be uint16_t here (as
you really mean "exactly 16 bits"), the
Thank you Anthony PERARD.
Thanks
Zhang Chen
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: Thursday, August 8, 2019 5:08 PM
> To: Zhang, Chen
> Cc: Ian Jackson ; Wei Liu ; xen-
> de...@lists.xenproject.org; Zhang Chen
> Subject: Re: [PATCH V4] to
On 08/08/2019 10:13, Julien Grall wrote:
> Hi Jan,
>
> On 08/08/2019 10:04, Jan Beulich wrote:
>> On 08.08.2019 10:43, Andrew Cooper wrote:
>>> On 08/08/2019 07:22, Jan Beulich wrote:
On 07.08.2019 21:41, Andrew Cooper wrote:
> --- /dev/null
> +++ b/docs/glossary.rst
> @@ -0,0 +1,3
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [
Here, we change all assembly code which is marked using END (and not
ENDPROC). We switch all these to appropriate new markings SYM_CODE_START
and SYM_CODE_END.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky [xen bits]
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@k
On Wed, Aug 07, 2019 at 05:03:46PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> > +BOOLEAN
> > +XenPvhDetected (
> > + VOID
> > + )
> > +{
> > + //
> > + // This function should only be used after XenConnect
> > + //
> > + ASSERT (mXenInfo.
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.
Sign
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.
So introduce macros with clear use to annotate assembly as follows:
a) Support macr
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END appropriatelly too.
Signed-off-by: Jiri Slaby
Reviewed-by: Boris Ostrovsky
There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether we use FUNC or CODE,
depends on whether ENDP
Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros to have:
8 OBJECT LOCAL DEFAULT6 gdt
000832 OBJECT LOCAL DEFAULT6 gdt_start
0028 0 OBJECT LOCAL DEFAULT6 gdt_end
0028 256 OBJECT LOCAL DEFAULT6 early_stack
0128 0 OBJECT LOCAL DEFAU
These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.
And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.
Signed-off-by: Jiri Slaby
Reviewed-by: Rafael J. Wysoc
On Thu, Aug 08, 2019 at 11:26:41AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 04:35:58PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:21PM +0100, Anthony PERARD wrote:
> > > Check if there's a start of the day struct provided to PVH guest, save
> > > the ACPI RSDP add
On Wed, Aug 07, 2019 at 05:14:33PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:31PM +0100, Anthony PERARD wrote:
> > When the Xen PVH entry point has been used, hvmloader hasn't run and
> > hasn't prepared an E820 table. The only way left to get an E820 table
> > is to ask Xen via
On Thu, Aug 08, 2019 at 11:38:13AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:03:46PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:29PM +0100, Anthony PERARD wrote:
> > > +BOOLEAN
> > > +XenPvhDetected (
> > > + VOID
> > > + )
> > > +{
> > > + //
> > > + // Thi
On Thu, Aug 08, 2019 at 11:41:18AM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:14:33PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:31PM +0100, Anthony PERARD wrote:
> > > When the Xen PVH entry point has been used, hvmloader hasn't run and
> > > hasn't prepared an
On 08.08.2019 11:13, Julien Grall wrote:
> Hi Jan,
>
> On 08/08/2019 10:04, Jan Beulich wrote:
>> On 08.08.2019 10:43, Andrew Cooper wrote:
>>> On 08/08/2019 07:22, Jan Beulich wrote:
On 07.08.2019 21:41, Andrew Cooper wrote:
> --- /dev/null
> +++ b/docs/glossary.rst
> @@ -0,0 +1,
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU be accessible by DOM0.
Signed-off-by: Oleksandr Tyshchenko
---
I have heard there is a "possible" case when the IOMMU could be a
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
> forcibly disabled in bootargs (e.g. "iommu=0") in order to let
> the IOMMU be accessible by DOM0.
>
> Signed-off-by: Oleksan
On 08.08.19 10:05, Jan Beulich wrote:
Hi Jan
(I'm sorry if you receive duplicates of this, but I've got a reply
back from our mail system that several of the recipients did not
have their host names resolved correctly on the first attempt.)
Absolutely no problem.
Jan, how this could be te
On Wed, Aug 07, 2019 at 05:34:32PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:32PM +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
> > work without CMOS
flight 139796 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 139766
Tests which did n
On Aug 8, 2019, at 06:49, Jan Beulich wrote:
>
>> On 08.08.2019 11:13, Julien Grall wrote:
>> Hi Jan,
>>
>>> On 08/08/2019 10:04, Jan Beulich wrote:
On 08.08.2019 10:43, Andrew Cooper wrote:
> On 08/08/2019 07:22, Jan Beulich wrote:
>> On 07.08.2019 21:41, Andrew Cooper wrote:
>
On 08.08.19 14:01, Roger Pau Monné wrote:
Hi, Roger.
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU
On Thu, Aug 08, 2019 at 10:40:36AM +0100, Andrew Cooper wrote:
> On 08/08/2019 01:31, Marek Marczykowski-Górecki wrote:
> > When booting Xen via xen.efi, there is /mapbs option to workaround
> > certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
> > map EfiBootServices{Code,Data
On Thu, Aug 08, 2019 at 02:23:51PM +0300, Oleksandr wrote:
>
> On 08.08.19 14:01, Roger Pau Monné wrote:
>
> Hi, Roger.
>
>
> > On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
> > > From: Oleksandr Tyshchenko
> > >
> > > Don't skip IOMMU nodes when creating DT for Dom0 i
On 08.08.2019 11:45, Andrew Cooper wrote:
> On 08/08/2019 10:08, Jan Beulich wrote:
>> On 08.08.2019 10:33, Andrew Cooper wrote:
>>> On 08/08/2019 05:50, Juergen Gross wrote:
On 07.08.19 20:11, Andrew Cooper wrote:
>
> Its not exactly the easiest to dump to follow.
>
> First o
On 08.08.19 12:28, Julien Grall wrote:
On 08/08/2019 08:51, Juergen Gross wrote:
On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
Do we have an implied assumption somewhere that unsigned short is
exactly 16 bits wide? I think "val" wants to be uint16_t here (as
On 08.08.2019 12:28, Julien Grall wrote:
> On 08/08/2019 08:51, Juergen Gross wrote:
>> On 08.08.19 08:58, Jan Beulich wrote:
>>> On 07.08.2019 16:31, Juergen Gross wrote:
>>> Do we have an implied assumption somewhere that unsigned short is
>>> exactly 16 bits wide? I think "val" wants to be uint1
On 08.08.19 12:20, Andrew Cooper wrote:
On 08/08/2019 10:36, Juergen Gross wrote:
On 08.08.19 10:33, Andrew Cooper wrote:
On 08/08/2019 05:50, Juergen Gross wrote:
On 07.08.19 20:11, Andrew Cooper wrote:
Its not exactly the easiest to dump to follow.
First of all - I don't see why the hold
On 08.08.2019 13:53, Juergen Gross wrote:
> On 08.08.19 12:28, Julien Grall wrote:
>> On 08/08/2019 08:51, Juergen Gross wrote:
>>> On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
Do we have an implied assumption somewhere that unsigned short is
exactl
This function determines, based on the given section name, if the
sections belongs to the special sections category.
Add more special sections to special_sections[] along with a new
undefined_group_size() helper function returning 0 (undefined).
New special sections are: .altinstr_replacement.
Si
On 08/08/2019 12:23, Oleksandr wrote:
On 08.08.19 14:01, Roger Pau Monné wrote:
Hi, Roger.
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e
Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.
This is a livepatch backport of kpatch upstream commit [1]:
kpatch-build: detect special section group sizes 170449847136a48b19fc
Xen onl
Hi, Julien.
I am afraid, I don't know a correct answer for this question. I would
leave this to maintainers.
I just followed sample copyright notice for GPL v2 License according
to the document:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=CONTRIBUTING
The file CONTRIBUTING is only
Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section has undefined group_size.
Allow to specify different .l
Older versions of GCC did not split .rodata.str sections by function.
Because of that, the entire section was always included.
The livepatch-build-tools commit [1] fixed patch creation and kept
including all .rodata.str sections, in order to maintain existing
behavior for GCC 6.1+.
This means all .
On 08.08.2019 11:40, Andrew Cooper wrote:
> On 08/08/2019 01:31, Marek Marczykowski-Górecki wrote:
>> When booting Xen via xen.efi, there is /mapbs option to workaround
>> certain platform issues (added in f36886bdf4 "EFI/early: add /mapbs to
>> map EfiBootServices{Code,Data}"). Add support for efi
Hi,
Removing Lars there is no need to spam him with technical discussion :)
On 08/08/2019 11:14, Oleksandr wrote:
Hi,
Hi, Julien.
Sorry for the possible format issues.
> No, it is not disabled. But, ipmmu_irq() uses another mmu->lock. So, I
> think, there won't be a deadlo
During verification check if all sections do not contain any entries
with undefined symbols (STN_UNDEF). This situation can happen when a
section is copied over from its original object to a patched object,
but various symbols related to the section are not copied along.
This scenario happens typic
Hi Stefano,
On 07/08/2019 23:46, Stefano Stabellini wrote:
On Tue, 15 Jan 2019, Julien Grall wrote:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index cc6b464..d48f77e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2094,6 +2094,88 @@ sta
On 08.08.19 14:18, Jan Beulich wrote:
On 08.08.2019 13:53, Juergen Gross wrote:
On 08.08.19 12:28, Julien Grall wrote:
On 08/08/2019 08:51, Juergen Gross wrote:
On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
Do we have an implied assumption somewhere that unsi
The patched ELF object file contains all sections and symbols as
resulted from the compilation. However, certain symbols may not be
copied over to the resulting object file, due to being unchanged or
not included for other reasons.
In such situation the resulting object file has the entire sections
Hi, Julien, Roger.
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU be accessible by DOM0.
I don'
On 08/08/2019 14:03, Oleksandr wrote:
Hi, Julien, Roger.
Hi,
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order
On 07.08.2019 19:42, Eslam Elnikety wrote:
> Support for FIFO event channel ABI was first introduced in Xen 4.4
> (see 88910061ec6). Make this support tunable, since the choice of which
> event channel ABI has implications for hibernation. Consider resuming a
> pre Xen 4.4 hibernated Linux guest. D
On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> > implementation. It will also be used by XenTimerDxe. Override
> > PcdFSBClock to match Xen vLAPIC time
On Thu, Aug 08, 2019 at 09:11:00PM +0800, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
Hi
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU be accessible by DOM0.
I don't think your
On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote:
> On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > > PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
> > > implementation. It will also b
Hi,
On 08/08/2019 14:36, Oleksandr wrote:
Hi
On Thu, Aug 08, 2019 at 01:53:23PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Don't skip IOMMU nodes when creating DT for Dom0 if IOMMU has been
forcibly disabled in bootargs (e.g. "iommu=0") in order to let
the IOMMU
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
drivers/block/xen-blkback/common.h |
On 05.08.2019 15:29, Julien Grall wrote:
> @@ -627,6 +629,15 @@ long do_console_io(int cmd, int count,
> XEN_GUEST_HANDLE_PARAM(char) buffer)
> rc = guest_console_write(buffer, count);
> break;
> case CONSOLEIO_read:
> +/*
> + * The return value is either
On 05.08.2019 15:29, Julien Grall wrote:
> @@ -1261,14 +1259,15 @@ void debugtrace_printk(const char *fmt, ...)
> ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0);
>
> va_start(args, fmt);
> -vsnprintf(buf, sizeof(buf), fmt, args);
> +nr = vscnprintf(buf, sizeof(buf), fmt, arg
On 08/08/2019 14:57, Jan Beulich wrote:
On 05.08.2019 15:29, Julien Grall wrote:
@@ -627,6 +629,15 @@ long do_console_io(int cmd, int count,
XEN_GUEST_HANDLE_PARAM(char) buffer)
rc = guest_console_write(buffer, count);
break;
case CONSOLEIO_read:
+/*
+
On 06.08.19 16:09, Andrii Anisov wrote:
p.p.s. I'm looking through freertos as well to get wider look on the available
approaches
OK, basically Free-RTOS does not account the IRQ time separately. Yet its
scheduling is very implementation dependent.
Any ideas about other open-source examples
On Wed, 7 Aug 2019 08:25:37 +
wrote:
> Rename ALIGNED_ONLY to TARGET_ALIGNED_ONLY for clarity and move
> defines out of target/foo/cpu.h into configure, as we do with
> TARGET_WORDS_BIGENDIAN, so that it is always defined early.
>
> Poisoned TARGET_ALIGNED_ONLY to prevent use in common code.
Hi Jan,
On 08/08/2019 14:51, Jan Beulich wrote:
On 05.08.2019 15:29, Julien Grall wrote:
@@ -1261,14 +1259,15 @@ void debugtrace_printk(const char *fmt, ...)
ASSERT(debugtrace_buf[debugtrace_bytes - 1] == 0);
va_start(args, fmt);
-vsnprintf(buf, sizeof(buf), fmt, args);
+
On 05.08.2019 15:29, Julien Grall wrote:
> Currently, OS developpers will have to look at Xen code in order to know
> the parameters of an hypercall and how it is meant to work.
>
> This is not a trivial task as you may need to have a deep understanding
> of Xen internal.
>
> This patch attempts
On Wed, 7 Aug 2019 08:26:23 +
wrote:
> Preparation for collapsing the two byte swaps, adjust_endianness and
> handle_bswap, along the I/O path.
>
> Target dependant attributes are conditionalize upon NEED_CPU_H.
s/conditionalize/conditionalized/ ?
>
> Signed-off-by: Tony Nguyen
> Acked-b
On 07/08/2019, 20:15, "Julien Grall" wrote:
(+ Lars)
Hi,
On 8/7/19 5:01 PM, Oleksandr wrote:
>>> + * you can found at:
>>> + *url:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
>>> + *branch: v4.14.75-ltsi/rcar-3.9.6
On Thu, Aug 08, 2019 at 03:44:23PM +0200, Roger Pau Monné wrote:
> On Thu, Aug 08, 2019 at 02:28:32PM +0100, Anthony PERARD wrote:
> > On Wed, Aug 07, 2019 at 05:54:51PM +0200, Roger Pau Monné wrote:
> > > On Mon, Jul 29, 2019 at 04:39:38PM +0100, Anthony PERARD wrote:
> > > > PcdFSBClock is used b
On Wed, Aug 07, 2019 at 06:09:57PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:44PM +0100, Anthony PERARD wrote:
> > A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> > PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
> > firmware from finish to boot.
On Wed, Aug 07, 2019 at 06:07:03PM +0200, Roger Pau Monné wrote:
> On Mon, Jul 29, 2019 at 04:39:42PM +0100, Anthony PERARD wrote:
> > XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
> > Grant Tables.
> >
> > The call is only done if it is necessary, we simply detect if the
> >
1 - 100 of 165 matches
Mail list logo
