On 6/21/2023 9:04 PM, Peter Zijlstra wrote:
> On Wed, Jun 21, 2023 at 07:19:21PM +0000, Per Bilse wrote:
>> On 6/21/2023 5:40 PM, Peter Zijlstra wrote:
>>> I don't understand it -- fundamentally, how can linux schedule when the
>>> guest isn't even running?
On 6/21/2023 5:40 PM, Peter Zijlstra wrote:
> I don't understand it -- fundamentally, how can linux schedule when the
> guest isn't even running? Hypercall transfers control to the
> host/hypervisor and leaves the guest suspended.
Hi Peter, as noted in earlier note to Andy, this is essentially
On 6/21/2023 5:27 PM, Andy Lutomirski wrote:
> This code is a horrible mess, with and without your patches. I think that,
> if this were new, there's no way it would make it in to the kernel.
Hi Andy, and many thanks for your frank assessments. Generally, this
is indeed somewhat old code,
ture will livepatch that
function to a no-op unless full preemption is selected. The code is
therefore updated to call raw_irqentry_exit_cond_resched().
Signed-off-by: Per Bilse
---
arch/x86/entry/common.c | 34 +-
drivers/xen/privcmd.c | 12 ++---
Provide a user-friendly option to specify preferred reboot details at
compile time. It uses the same internals as the command line 'reboot'
parameter, and will be overridden by a choice on the command line.
Signed-off-by: Per Bilse
---
v2: Incorporate feedback from initial patch. Separating
On 18/01/2023 07:15, Jan Beulich wrote:
> On 17.01.2023 20:28, Per Bilse wrote:
>> On 17/01/2023 15:55, Jan Beulich wrote:
>>> On 16.01.2023 18:21, Per Bilse wrote:
>>>> + config REBOOT_METHOD_XEN
>>>> + bool "xen"
>>>> +
On 17/01/2023 15:55, Jan Beulich wrote:
> On 16.01.2023 18:21, Per Bilse wrote:
>> +config REBOOT_SYSTEM_DEFAULT
>> +default y
>> +bool "Xen-defined reboot method"
>
> May I ask that you swap the two lines? (Personally I consider kconfig
> to
' rather than 'reboot type' as
used in the code. A 'type' suggests something to happen after the
reboot, akin to a UNIX run level, whereas 'method' clearly identifies
how the reboot will be achieved. I thought it best for this to be
clear in an outward facing utility.
Signed-off-by: Per Bilse
es, one for each bit, returning '1' if set, '0' otherwise.
Two known flags, 'privileged' and 'initdomain', are explicitly named,
and all remaining flags can be accessed via generically named files,
as suggested by Andrew Cooper.
Signed-off-by: Per Bilse
---
v2: minor fix to layout, incorporate suggestion
es, one for each bit, returning '1' if set, '0' otherwise.
Two known flags, 'privileged' and 'initdomain', are explicitly named,
and all remaining flags can be accessed via generically named files,
as suggested by Andrew Cooper.
Signed-off-by: Per Bilse
---
v2: minor fix to layout, incorporate suggestion
On 09/12/2022 09:04, Juergen Gross wrote:
> On 02.12.22 19:22, Per Bilse wrote:
>> +Description: If running under Xen:
>> + All bits in Xen's start-flags are represented as
>> + boolean files, returning '1' if set, '0' otherwise.
>
> I think at
Avoid incorrectly triggering an error when a broadcast buffered ioreq
is not handled by all registered clients, as long as the failure is
strictly because the client doesn't handle buffered ioreqs.
Signed-off-by: Per Bilse
---
v2: Complete rethink with better information. A lot of simplicity
On 28/11/2022 08:21, Jan Beulich wrote:
> In addition I think ignoring failure (and, as said by Julien, only because
> of no bufioreq being registered) is (kind of implicitly) valid only for
> buffered requests. Hence I'm unconvinced of the need of a new boolean
> function parameter. Instead I
es, one for each bit, returning '1' if set, '0' otherwise.
Two known flags, 'privileged' and 'initdomain', are explicitly named,
and all remaining flags can be accessed via generically named files,
as suggested by Andrew Cooper.
This patch replaces previous suggestion for SIF flags exposure in its
entirety.
On 29/11/2022 16:41, Andrew Cooper wrote:
> As for the actual flags exposed, it would be very beneficial not to copy
> the exist proc interface. It would be better to expose a subdir that
> had files containing booleans, because that also gives userspace an easy
> way to figure out if the
On 29/11/2022 16:29, Boris Ostrovsky wrote:
> Why not simply show unprocessed xen_start_flags as a hex value?
Providing a text representation follows what is currently the case:
[root@lcy2-dt128 /proc/xen]# cat capabilities
control_d
[root@lcy2-dt128 /proc/xen]#
The migrated form would yield:
exist with /proc/xen while dependencies are being migrated.
Possible values are "privileged", "initdomain", "multiboot",
"mod_start_pfn", and "virtmap", with "initdomain" being the equivalent
of "control_d".
Signed-off-by: Per Bilse
On 28/11/2022 08:21, Jan Beulich wrote:
> On 26.11.2022 23:19, Julien Grall wrote:
>>
>> The commit message is quite vague, so it is hard to know what you are
>> trying to solve exactly. AFAIU, there are two reasons for
>> ioreq_broadcast to fails:
>>1) The IOREQ server didn't register the
A change to XAPI varstored causes an unnecessary error message
to be logged in hypervisor.log whenever an RTC timeoffset update
is broadcast. In extreme cases this could flood the log file.
This patch modifies ioreq_broadcast() to allow partial success.
Signed-off-by: Per Bilse
---
xen/arch
19 matches
Mail list logo
