On 08.09.22 06:24, Viresh Kumar wrote:
On 07-09-22, 18:49, Julien Grall wrote:
Looking at this series, you will add ~250 lines (assuming your new patch)
for the i2c and then likely the same amount for GPIO.
I am assuming that for every new virtio device (e.g. gps, sound,
display...), we would a
On Wed, Sep 7, 2022 at 11:35 PM Kent Overstreet
wrote:
>
> On Wed, Sep 07, 2022 at 09:45:18AM -0400, Steven Rostedt wrote:
> > On Wed, 7 Sep 2022 09:04:28 -0400
> > Kent Overstreet wrote:
> >
> > > On Wed, Sep 07, 2022 at 01:00:09PM +0200, Michal Hocko wrote:
> > > > Hmm, it seems that further di
On Wed, Sep 07, 2022 at 09:45:18AM -0400, Steven Rostedt wrote:
> On Wed, 7 Sep 2022 09:04:28 -0400
> Kent Overstreet wrote:
>
> > On Wed, Sep 07, 2022 at 01:00:09PM +0200, Michal Hocko wrote:
> > > Hmm, it seems that further discussion doesn't really make much sense
> > > here. I know how to use
On 07.09.2022 16:33, Julien Grall wrote:
> On 25/08/2022 08:17, Jan Beulich wrote:
>> I haven't been able to find evidence of "-nopie" ever having been a
>> supported compiler option. The correct spelling is "-no-pie".
>> Furthermore like "-pie" this is an option which is solely passed to the
>> li
On 07-09-22, 19:02, Julien Grall wrote:
> It is a very descriptive compatible :). And yes I realize this is the
> compatible chosen by upstream.
:)
> So this is exposing a GPIO interrupt controller but IIUC we will also need
> to describe the devices in the device-tree. Can you outline how you wo
This commit firstly adds a bool field `static_heap` to bootinfo.
This newly introduced field is set at the device tree parsing time
if the static heap ranges are defined in the device tree chosen
node.
For Arm32, In `setup_mm`, if the static heap is enabled, we use the
static heap region for both
With the static heap setup, keep using xenheap_* in the function
setup_xenheap_mappings() will make the code confusing to read,
because we always need to map the full RAM on Arm64. Therefore,
renaming all "xenheap_*" variables to "directmap_*" to make clear
the area is used to access the RAM easily
This commit introduces the static heap memory, which is parts of RAM
reserved in the beginning of the boot time for heap.
Firstly, since a new type of memory bank is needed for marking the
memory bank solely as the heap, this commit defines `enum membank_type`
and use this enum in function device_
At the boot time, it is saner to stop booting early if an error occurs
when parsing the device tree chosen node, rather than seeing random
behavior afterwards. Therefore, this commit changes the return type of
the process_chosen_node() from void to int, and return correct errno
based on the error t
The static heap, or statically configured heap, refers to parts
of RAM reserved in the beginning for heap. Like the static memory
allocation, such static heap regions are reserved by configuration
in the device tree using physical address ranges.
This feature is useful to run Xen on Arm MPU system
On 07-09-22, 18:49, Julien Grall wrote:
> Looking at this series, you will add ~250 lines (assuming your new patch)
> for the i2c and then likely the same amount for GPIO.
>
> I am assuming that for every new virtio device (e.g. gps, sound,
> display...), we would also need to 250 lines of code. I
Hi stefano
> -Original Message-
> From: Stefano Stabellini
> Sent: Thursday, September 8, 2022 8:16 AM
> To: Julien Grall
> Cc: Penny Zheng ; xen-devel@lists.xenproject.org;
> Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v7 7/9] xen/arm:
flight 173053 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173053/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173048 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd broken
build-i386-libvirt6 libvirt-buil
flight 173046 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173046/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v4 3/4] xen/arm: mm: Rename xenheap_* variable to
> directmap_*
>
> Hi Henry,
>
> On 07/09/2022 15:35, Henry Wang wrote:
> > With the static heap setup, keep using xenheap_* in the function
> > setup_xenheap_mapp
Hi Julien,
> -Original Message-
> From: Julien Grall
> > +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
> > +
> > +Specify the number of cells used for the address and size of the
> > +"xen,static-heap" property under "chosen".
>
> Logging here just because it
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> > I would not block this series on the renaming for existing property (what
> > matter is the new ones are consistent with the discussion). The renaming
> could
> > be done afterwards. I would even say post the feature freeze o
flight 173044 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173044/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 buil
flight 173052 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Wed, 7 Sep 2022, Stefano Stabellini wrote:
> On Wed, 7 Sep 2022, Julien Grall wrote:
> > On 07/09/2022 14:49, Henry Wang wrote:
> > > > -Original Message-
> > > > From: Bertrand Marquis
> > > > > > > > But in any case we should only add one pair here for sure, as
> > > > > > > > you
>
On Wed, 7 Sep 2022, Julien Grall wrote:
> On 06/09/2022 09:59, Penny Zheng wrote:
> > We expose the shared memory to the domU using the "xen,shared-memory-v1"
> > reserved-memory binding. See
> > Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
> > in Linux for the correspond
On Wed, 7 Sep 2022, Rahul Singh wrote:
> Introduce a new sub-node under /chosen node to establish static event
> channel communication between domains on dom0less systems.
>
> An event channel will be created beforehand to allow the domains to
> send notifications to each other.
>
> Signed-off-by
On Wed, 7 Sep 2022, Rahul Singh wrote:
> Introduce a new "xen,enhanced" dom0less property value "no-xenstore" to
> disable xenstore interface for dom0less guests.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Stefano Stabellini
> ---
> Changes in v5:
> - fix minor comments
> - change unit64_t
On Wed, 7 Sep 2022, Julien Grall wrote:
> On 07/09/2022 14:49, Henry Wang wrote:
> > > -Original Message-
> > > From: Bertrand Marquis
> > > > > > > But in any case we should only add one pair here for sure, as you
> > > > > > > say
> > > the
> > > > > > > only implication is to add a coup
On Wed, 7 Sep 2022, Michal Orzel wrote:
> When dealing with device trees, we need to have a solution to add
> custom phandles to the nodes we create/modify. Add a global variable
> phandle_next to act as a countdown counter starting with the highest
> valid phandle value 0xfffe. Add a new funct
On Wed, 7 Sep 2022, Michal Orzel wrote:
> Introduce support for creating boot-time cpupools in the device tree and
> assigning them to dom0less domUs. Add the following options:
> - CPUPOOL[number]="cpu@1,...,cpu@N scheduler" to specify the
>list of cpus' node names and the scheduler to be use
On Wed, 7 Sep 2022, Julien Grall wrote:
> Hi Jan,
>
> On 07/09/2022 13:06, Jan Beulich wrote:
> > On 07.09.2022 13:09, Rahul Singh wrote:
> > > is_memory_hole was implemented for x86 and not for ARM when introduced.
> > > Replace is_memory_hole call to pci_check_bar as function should check
> > >
flight 173050 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173040 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
(+ Bertrand)
Hi Viresh,
On 22/08/2022 10:15, Viresh Kumar wrote:
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/g
Hi Viresh,
Jumping in the conversation.
On 07/09/2022 13:32, Viresh Kumar wrote:
I don't have much knowledge of the Xen code and wanted this code for I2C and
GPIO to be tested on Xen for the work we are doing around hypervisor agnostic
backends [1].
I started looking for a simple device's impl
flight 173047 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On 07/09/2022 16:30, Julien Grall wrote:
> Hi all,
>
> I think mentioned it privately a while a go, but never sent an e-mail
> about it.
>
> While testing arm32 with IOREQ, I noticed Xen is crashing because an
> alignment fault:
>
> (XEN) Data Abort Trap. Syndrome=0x1800061
> (XEN) Walking Hypervis
Static event channel support will be added for dom0less domains. Modify
evtchn_bind_interdomain to support static evtchn.
It is necessary to have access to the evtchn_bind_interdomain function
to do that, so make evtchn_bind_interdomain global and also make it
__must_check.
Currently evtchn_bind_
Introduce a new sub-node under /chosen node to establish static event
channel communication between domains on dom0less systems.
An event channel will be created beforehand to allow the domains to
send notifications to each other.
Signed-off-by: Rahul Singh
---
Changes in v5:
- fix minor commen
Introduce a new "xen,enhanced" dom0less property value "no-xenstore" to
disable xenstore interface for dom0less guests.
Signed-off-by: Rahul Singh
---
Changes in v5:
- fix minor comments
- change unit64_t to uint16_t for dom0less_feature
Changes in v4:
- Implement defines for dom0less features
Currently evtchn_alloc_unbound() always allocates the next available
port. Static event channel support for dom0less domains requires
allocating a specified port.
Modify the evtchn_alloc_unbound() to accept the port number as an
argument and allocate the specified port if available. If the port
nu
Restrict the maximum number of evtchn supported for domUs to avoid
allocating a large amount of memory in Xen.
Set the default value of max_evtchn_port to 1023. The value of 1023
should be sufficient for guests because on ARM we don't bind physical
interrupts to event channels. The only use of the
From: Stanislav Kinsburskii
In a follow-up patch we will want to either reserve or allocate a port
for various event channel helpers.
A new wrapper is introduced to either reserve a given port or allocate
a fresh one if zero.
Take the opportunity to replace the open-coded version in
evtchn_bind
From: Julien Grall
Since commit 01280dc19cf3 "evtchn: simplify port_is_valid()", the event
channels code assumes that all the buckets below d->valid_evtchns are
always allocated.
This assumption hold in most of the situation because a guest is not
allowed to chose the port. Instead, it will be t
The purpose of this patch series is to add the static event channel signaling
support to Xen on Arm based on design doc [1].
[1] https://lists.xenproject.org/archives/html/xen-devel/2022-05/msg01160.html
Julien Grall (1):
xen/evtchn: Make sure all buckets below d->valid_evtchns are allocated
R
Hi Julien,
> On 7 Sep 2022, at 16:30, Julien Grall wrote:
>
> Hi all,
>
> I think mentioned it privately a while a go, but never sent an e-mail about
> it.
>
> While testing arm32 with IOREQ, I noticed Xen is crashing because an
> alignment fault:
>
> (XEN) Data Abort Trap. Syndrome=0x18000
Hi Henry,
On 07/09/2022 15:35, Henry Wang wrote:
With the static heap setup, keep using xenheap_* in the function
setup_xenheap_mappings() will make the code confusing to read,
because we always need to map the full RAM on Arm64. Therefore,
renaming all "xenheap_*" variables to "directmap_*" to
Hi Henry,
On 07/09/2022 15:35, Henry Wang wrote:
+Static Heap Memory
+==
+
+The static heap memory refers to parts of RAM reserved in the beginning of
+boot time for heap. The memory is reserved by configuration in the device
+tree using physical address ranges.
+
+The static hea
Hi all,
I think mentioned it privately a while a go, but never sent an e-mail
about it.
While testing arm32 with IOREQ, I noticed Xen is crashing because an
alignment fault:
(XEN) Data Abort Trap. Syndrome=0x1800061
(XEN) Walking Hypervisor VA 0x40027ebb on CPU0 via TTBR 0x4012f000
Ajay Kaher writes:
> During boot-time there are many PCI config reads, these could be performed
> either using Port IO instructions (PIO) or memory mapped I/O (MMIO).
>
> PIO are less efficient than MMIO, they require twice as many PCI accesses
> and PIO instructions are serializing. As a result,
flight 173037 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173037/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
On Wed, Sep 07, 2022 at 12:21:12PM +, Dario Faggioli wrote:
> On Tue, 2022-09-06 at 14:35 +0200, Marek Marczykowski-Górecki wrote:
> > On Tue, Sep 06, 2022 at 01:46:55PM +0200, Juergen Gross wrote:
> > >
> > > Could you test the attached patch, please?
> >
> > I did a test with only dom0 runn
With the static heap setup, keep using xenheap_* in the function
setup_xenheap_mappings() will make the code confusing to read,
because we always need to map the full RAM on Arm64. Therefore,
renaming all "xenheap_*" variables to "directmap_*" to make clear
the area is used to access the RAM easily
This commit firstly adds a bool field `static_heap` to bootinfo.
This newly introduced field is set at the device tree parsing time
if the static heap ranges are defined in the device tree chosen
node.
For Arm32, In `setup_mm`, if the static heap is enabled, we use the
static heap region for both
This commit introduces the static heap memory, which is parts of RAM
reserved in the beginning of the boot time for heap.
Firstly, since a new type of memory bank is needed for marking the
memory bank solely as the heap, this commit defines `enum membank_type`
and use this enum in function device_
At the boot time, it is saner to stop booting early if an error occurs
when parsing the device tree chosen node, rather than seeing random
behavior afterwards. Therefore, this commit changes the return type of
the process_chosen_node() from void to int, and return correct errno
based on the error t
The static heap, or statically configured heap, refers to parts
of RAM reserved in the beginning for heap. Like the static memory
allocation, such static heap regions are reserved by configuration
in the device tree using physical address ranges.
This feature is useful to run Xen on Arm MPU system
Hi Jan,
On 25/08/2022 08:17, Jan Beulich wrote:
I haven't been able to find evidence of "-nopie" ever having been a
supported compiler option. The correct spelling is "-no-pie".
Furthermore like "-pie" this is an option which is solely passed to the
linker. The compiler only recognizes "-fpie" /
Hi Julien,
> On 7 Sep 2022, at 2:01 pm, Julien Grall wrote:
>
>
>
> On 06/09/2022 14:40, Rahul Singh wrote:
>> Restrict the maximum number of evtchn supported for domUs to avoid
>> allocating a large amount of memory in Xen.
>> Set the default value of max_evtchn_port to 1023. The value of 102
Hi Julien,
> On 7 Sep 2022, at 2:09 pm, Julien Grall wrote:
>
> Hi Rahul
>
> On 06/09/2022 14:40, Rahul Singh wrote:
>> Introduce a new "xen,enhanced" dom0less property value "no-xenstore" to
>> disable xenstore interface for dom0less guests.
>> Signed-off-by: Rahul Singh
>> ---
>> Changes in
Hi Julien,
> -Original Message-
> From: Julien Grall
> > I think I've addressed all comments from Julien regarding my series,
>
> If it is not too late for you would you be able to resend your series
> without the 'address-cells'/'size-cells' change? This will give me the
> opportunity t
On 07/09/2022 15:04, Julien Grall wrote:
Hi Henry,
On 07/09/2022 14:49, Henry Wang wrote:
-Original Message-
From: Bertrand Marquis
But in any case we should only add one pair here for sure, as you
say
the
only implication is to add a couple of 0 in the worst case.
I agree. The o
Hi Henry,
On 07/09/2022 14:49, Henry Wang wrote:
-Original Message-
From: Bertrand Marquis
But in any case we should only add one pair here for sure, as you say
the
only implication is to add a couple of 0 in the worst case.
I agree. The only drawback is the need to modify the alrea
Hi Henry,
> On 7 Sep 2022, at 14:49, Henry Wang wrote:
>
> Hi Bertrand and Michal,
>
> I don't want to spam the email so I just reply here...
>
>> -Original Message-
>> From: Bertrand Marquis
>> But in any case we should only add one pair here for sure, as you say
>> the
>> on
On 07/09/2022 02:51, Penny Zheng wrote:
Hi Julien
Hi Penny,
-Original Message-
From: Julien Grall
Sent: Wednesday, September 7, 2022 2:01 AM
To: Penny Zheng ; xen-devel@lists.xenproject.org
Cc: Wei Chen ; Stefano Stabellini
; Bertrand Marquis ;
Volodymyr Babchuk ; Henry Wang
Su
Hi Bertrand and Michal,
I don't want to spam the email so I just reply here...
> -Original Message-
> From: Bertrand Marquis
> But in any case we should only add one pair here for sure, as you say
> the
> only implication is to add a couple of 0 in the worst case.
> >>> I agree
Hi,
On 06/09/2022 12:59, Michal Orzel wrote:
On 06/09/2022 10:59, Penny Zheng wrote:
on ARM, static memory sharing is tech preview, which shall be documented
in SUPPORT.md
Signed-off-by: Penny Zheng
Reviewed-by: Michal Orzel
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
> On 7 Sep 2022, at 14:37, Michal Orzel wrote:
>
>
>
> On 07/09/2022 15:33, Bertrand Marquis wrote:
>>
>>> On 7 Sep 2022, at 14:31, Michal Orzel wrote:
>>>
>>>
>>>
>>> On 07/09/2022 15:28, Bertrand Marquis wrote:
Hi Michal,
> On 7 Sep 2022, at 14:09, Michal Orzel
Hi Henry,
> On 7 Sep 2022, at 14:35, Henry Wang wrote:
>
> Hi Michal,
>
>> -Original Message-
>> From: Michal Orzel
>>> I am not convinced by the arguments on not using #address-cells and will
>>> leave that one to Stefano
>>>
>>> But in any case we should only add one pair here for s
On Wed, 7 Sep 2022 09:04:28 -0400
Kent Overstreet wrote:
> On Wed, Sep 07, 2022 at 01:00:09PM +0200, Michal Hocko wrote:
> > Hmm, it seems that further discussion doesn't really make much sense
> > here. I know how to use my time better.
>
> Just a thought, but I generally find it more product
Hi Penny,
On 06/09/2022 09:59, Penny Zheng wrote:
We expose the shared memory to the domU using the "xen,shared-memory-v1"
reserved-memory binding. See
Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
in Linux for the corresponding device tree binding.
To save the cost of
On 07/09/2022 15:33, Bertrand Marquis wrote:
>
>> On 7 Sep 2022, at 14:31, Michal Orzel wrote:
>>
>>
>>
>> On 07/09/2022 15:28, Bertrand Marquis wrote:
>>>
>>> Hi Michal,
>>>
On 7 Sep 2022, at 14:09, Michal Orzel wrote:
On 07/09/2022 14:45, Julien Grall wrote:
>
>
Hi Michal,
> -Original Message-
> From: Michal Orzel
> > I am not convinced by the arguments on not using #address-cells and will
> > leave that one to Stefano
> >
> > But in any case we should only add one pair here for sure, as you say the
> > only implication is to add a couple of 0 in
> On 7 Sep 2022, at 14:31, Michal Orzel wrote:
>
>
>
> On 07/09/2022 15:28, Bertrand Marquis wrote:
>>
>> Hi Michal,
>>
>>> On 7 Sep 2022, at 14:09, Michal Orzel wrote:
>>>
>>>
>>> On 07/09/2022 14:45, Julien Grall wrote:
On 07/09/2022 13:41, Michal Orzel wrote:
>
>
On 07/09/2022 15:28, Bertrand Marquis wrote:
>
> Hi Michal,
>
>> On 7 Sep 2022, at 14:09, Michal Orzel wrote:
>>
>>
>> On 07/09/2022 14:45, Julien Grall wrote:
>>>
>>> On 07/09/2022 13:41, Michal Orzel wrote:
On 07/09/2022 14:32, Julien Grall wrote:
> [CAUTION: External Ema
Hi,
> On 7 Sep 2022, at 14:21, Jan Beulich wrote:
>
> On 07.09.2022 15:13, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 7 Sep 2022, at 13:06, Jan Beulich wrote:
>>>
>>> On 07.09.2022 13:09, Rahul Singh wrote:
is_memory_hole was implemented for x86 and not for ARM when introduced.
Re
Hi Michal,
> On 7 Sep 2022, at 14:09, Michal Orzel wrote:
>
>
> On 07/09/2022 14:45, Julien Grall wrote:
>>
>> On 07/09/2022 13:41, Michal Orzel wrote:
>>>
>>>
>>> On 07/09/2022 14:32, Julien Grall wrote:
[CAUTION: External Email]
On 07/09/2022 13:12, Michal Orzel wrote:
Hi,
> On 7 Sep 2022, at 13:48, Julien Grall wrote:
>
> Hi Jan,
>
> On 07/09/2022 13:06, Jan Beulich wrote:
>> On 07.09.2022 13:09, Rahul Singh wrote:
>>> is_memory_hole was implemented for x86 and not for ARM when introduced.
>>> Replace is_memory_hole call to pci_check_bar as function should c
On 07.09.2022 15:13, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 7 Sep 2022, at 13:06, Jan Beulich wrote:
>>
>> On 07.09.2022 13:09, Rahul Singh wrote:
>>> is_memory_hole was implemented for x86 and not for ARM when introduced.
>>> Replace is_memory_hole call to pci_check_bar as function should che
Hi Jan,
> On 7 Sep 2022, at 13:06, Jan Beulich wrote:
>
> On 07.09.2022 13:09, Rahul Singh wrote:
>> is_memory_hole was implemented for x86 and not for ARM when introduced.
>> Replace is_memory_hole call to pci_check_bar as function should check
>> if device BAR is in defined memory range. Also,
Hi,
> On 7 Sep 2022, at 13:45, Julien Grall wrote:
>
>
>
> On 07/09/2022 13:41, Michal Orzel wrote:
>> On 07/09/2022 14:32, Julien Grall wrote:
>>> [CAUTION: External Email]
>>>
>>> On 07/09/2022 13:12, Michal Orzel wrote:
Hi Julien,
>>>
>>> Hi Michal,
>>>
On 07/09/2022 13:36, Jul
On 07/09/2022 14:45, Julien Grall wrote:
>
> On 07/09/2022 13:41, Michal Orzel wrote:
>>
>>
>> On 07/09/2022 14:32, Julien Grall wrote:
>>> [CAUTION: External Email]
>>>
>>> On 07/09/2022 13:12, Michal Orzel wrote:
Hi Julien,
>>>
>>> Hi Michal,
>>>
On 07/09/2022 13:36, Julien Grall wro
Hi Rahul
On 06/09/2022 14:40, Rahul Singh wrote:
Introduce a new "xen,enhanced" dom0less property value "no-xenstore" to
disable xenstore interface for dom0less guests.
Signed-off-by: Rahul Singh
---
Changes in v4:
- Implement defines for dom0less features
Changes in v3:
- new patch in thi
On Wed, Sep 07, 2022 at 01:00:09PM +0200, Michal Hocko wrote:
> Hmm, it seems that further discussion doesn't really make much sense
> here. I know how to use my time better.
Just a thought, but I generally find it more productive to propose ideas than to
just be disparaging.
Cheers,
Kent
On 06/09/2022 14:40, Rahul Singh wrote:
Restrict the maximum number of evtchn supported for domUs to avoid
allocating a large amount of memory in Xen.
Set the default value of max_evtchn_port to 1023. The value of 1023
should be sufficient for domUs guests because on ARM we don't bind
To me
flight 173034 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173034/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
flight 173043 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173043/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Wed, Sep 07, 2022 at 02:34:25PM +0200, Jan Beulich wrote:
> On 07.09.2022 14:20, Bertrand Marquis wrote:
> > Hi Leo,
> >
> > Thanks a lot for the quick handling here.
> >
> >> On 7 Sep 2022, at 13:04, Leo Yan wrote:
> >>
> >> On Arm64 Linux kernel prints log for Xen version number:
> >>
> >>
On Arm64 Linux kernel prints log for Xen version number:
Xen XEN_VERSION.XEN_SUBVERSION support found
The header file "xen/compile.h" is missed so that XEN_VERSION and
XEN_SUBVERSION are not defined, __stringify() wrongly converts them as
strings and concatenate to string "XEN_VERSION.XEN_SUBVE
Hi Jan,
On 07/09/2022 13:06, Jan Beulich wrote:
On 07.09.2022 13:09, Rahul Singh wrote:
is_memory_hole was implemented for x86 and not for ARM when introduced.
Replace is_memory_hole call to pci_check_bar as function should check
if device BAR is in defined memory range. Also, add an implementa
On 07/09/2022 13:01, Jan Beulich wrote:
On 07.09.2022 12:00, Julien Grall wrote:
On 07/09/2022 10:07, Jan Beulich wrote:
On 07.09.2022 10:58, Julien Grall wrote:
On 06/09/2022 09:53, Jan Beulich wrote:
On 03.09.2022 02:24, Stefano Stabellini wrote:
On Thu, 1 Sep 2022, Rahul Singh wrote:
On 07/09/2022 13:41, Michal Orzel wrote:
On 07/09/2022 14:32, Julien Grall wrote:
[CAUTION: External Email]
On 07/09/2022 13:12, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 07/09/2022 13:36, Julien Grall wrote:
Hi Henry,
While reviewing the binding sent by Penny I noticed some inc
On 07/09/2022 14:32, Julien Grall wrote:
> [CAUTION: External Email]
>
> On 07/09/2022 13:12, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 07/09/2022 13:36, Julien Grall wrote:
>>>
>>> Hi Henry,
>>>
>>> While reviewing the binding sent by Penny I noticed some inconsistency
>>> wit
On 07/09/2022 13:12, Bertrand Marquis wrote:
Hi,
Hi Bertrand,
On 7 Sep 2022, at 12:48, Henry Wang wrote:
Hi Julien,
-Original Message-
From: Julien Grall
Subject: Re: [PATCH v3 2/4] docs, xen/arm: Introduce static heap memory
Hi Henry,
While reviewing the binding sent by Pen
On 07.09.2022 14:20, Bertrand Marquis wrote:
> Hi Leo,
>
> Thanks a lot for the quick handling here.
>
>> On 7 Sep 2022, at 13:04, Leo Yan wrote:
>>
>> On Arm64 Linux kernel prints log for Xen version number:
>>
>> Xen XEN_VERSION.XEN_SUBVERSION support found
>>
>> The header file "xen/compile.
On Wed, Sep 07, 2022 at 02:31:52PM +0200, Jan Beulich wrote:
> On 07.09.2022 14:28, Leo Yan wrote:
> > A question, since commit 5d797ee199b3 was merged in 4.11.0-rc6, for
> > fixing it, should I explictly add backport tag as below?
> >
> > Backport: 4.11+
>
> That's up to you, I would say. We d
Hi Anthony,
Thanks a lot for the in-depth review, it is really helpful.
I don't have much knowledge of the Xen code and wanted this code for I2C and
GPIO to be tested on Xen for the work we are doing around hypervisor agnostic
backends [1].
I started looking for a simple device's implementation
On 07/09/2022 13:12, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 07/09/2022 13:36, Julien Grall wrote:
Hi Henry,
While reviewing the binding sent by Penny I noticed some inconsistency
with the one you introduced. See below.
On 07/09/2022 09:36, Henry Wang wrote:
+- xen,static-heap
+
On 07.09.2022 14:28, Leo Yan wrote:
> A question, since commit 5d797ee199b3 was merged in 4.11.0-rc6, for
> fixing it, should I explictly add backport tag as below?
>
> Backport: 4.11+
That's up to you, I would say. We don't really use that tag all that much,
the Fixes: tag is more relevant at
Hi Jan,
On Wed, Sep 07, 2022 at 02:12:25PM +0200, Jan Beulich wrote:
> On 07.09.2022 14:04, Leo Yan wrote:
> > On Arm64 Linux kernel prints log for Xen version number:
> >
> > Xen XEN_VERSION.XEN_SUBVERSION support found
> >
> > The header file "xen/compile.h" is missed so that XEN_VERSION and
On Tue, 2022-09-06 at 14:35 +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Sep 06, 2022 at 01:46:55PM +0200, Juergen Gross wrote:
> >
> > Could you test the attached patch, please?
>
> I did a test with only dom0 running, and it works now. It isn't a
> comprehensive test, but just dom0 was en
Hi Leo,
Thanks a lot for the quick handling here.
> On 7 Sep 2022, at 13:04, Leo Yan wrote:
>
> On Arm64 Linux kernel prints log for Xen version number:
>
> Xen XEN_VERSION.XEN_SUBVERSION support found
>
> The header file "xen/compile.h" is missed so that XEN_VERSION and
> XEN_SUBVERSION are
Hi Julien,
On 07/09/2022 13:36, Julien Grall wrote:
>
> Hi Henry,
>
> While reviewing the binding sent by Penny I noticed some inconsistency
> with the one you introduced. See below.
>
> On 07/09/2022 09:36, Henry Wang wrote:
>> +- xen,static-heap
>> +
>> +Property under the top-level "chos
1 - 100 of 164 matches
Mail list logo
