On 2/13/19 1:31 AM, Rich Persaud wrote:
>> On Feb 11, 2019, at 05:05, Lars Kurth wrote:
>>
>> Hi all,
>>
>> we have the community call for February coming up this Wednesday. My sincere
>> apologies, that I have not asked for agenda items last week. A current
>> agenda (primarily a skeleton) is
On 2/12/19 11:42 AM, Razvan Cojocaru wrote:
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
>
> This can lead to domain crashes in the
as a replacement to make sure
> there's no overlapping with MMIO read-only ranges.
>
> Note that 1G MMIO entries will not be created unless mmio_order is
> changed to allow it.
>
> Signed-off-by: Roger Pau Monné
Acked-by: George Dunlap
> On Feb 15, 2019, at 1:47 PM, Andrew Cooper wrote:
>
> On 15/02/2019 13:37, George Dunlap wrote:
>>
>>>> The one issue is that domain_pause_except_self() currently is actually a
>>>> deadlock risk if two different vcpus start it at the same time.
> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru
> wrote:
>
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
Sorry to come in here on v4 and suggest
> On Feb 15, 2019, at 1:24 PM, Jan Beulich wrote:
>
On 15.02.19 at 13:52, wrote:
>>> On Feb 12, 2019, at 11:42 AM, Razvan Cojocaru
>>> wrote:
>>>
>>> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
>>> on purpose (as it was originally supposed to cater to a in-guest
> On Feb 15, 2019, at 2:02 PM, Jan Beulich wrote:
>
>>>> On 15.02.19 at 14:51, wrote:
>
>>
>>> On Feb 15, 2019, at 1:47 PM, Andrew Cooper
>>> wrote:
>>>
>>> On 15/02/2019 13:37, George Dunlap wrote:
>>>>
&g
> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
>
> This is in preparation for also changing p2m_entry_modify to return an
> error code.
>
> No functional change intended.
I think you need to explain wheny/why you’re using BUG_ON() rather than
ASSERT() or passing the caller up the
> On Feb 15, 2019, at 5:36 PM, Stefano Stabellini
> wrote:
>
> On Fri, 15 Feb 2019, George Dunlap wrote:
>>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini
>>> wrote:
>>>
>>> On Wed, 13 Feb 2019, Wei Liu wrote:
>>>> On
> On Feb 15, 2019, at 2:18 PM, Roger Pau Monne wrote:
>
> So that the specific handling can be removed from
> atomic_write_ept_entry and be shared with npt and shadow code.
>
> This commit also removes the check that prevent non-ept PVH dom0 from
> mapping foreign pages.
>
> Signed-off-by:
On 2/6/19 2:26 PM, Petre Ovidiu PIRCALABU wrote:
> On Wed, 2018-12-19 at 20:52 +0200, Petre Pircalabu wrote:
>> This patchset is a rework of the "multi-page ring buffer" for
>> vm_events
>> patch based on Andrew Cooper's comments.
>> For synchronous vm_events the ring waitqueue logic was
Signed-off-by: George Dunlap
---
Release justification:
- "Bug" in docs (credit1 is no longer default)
- No functional change
CC: Andrew Cooper
CC: Ian Jackson
CC: Jan Beulich
CC: Julien Grall
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Jue
Need a space between the paragraph and the list so pandoc knows it's a
list.
Signed-off-by: George Dunlap
---
Release justification:
- "Bug" in docs (incorrect HTML output generated)
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Tim Deegan
CC: Konrad Wilk
C
On Wed, Jul 18, 2018 at 11:23 PM Christopher Clark
wrote:
>
> gcc-8.1 complains:
>
> | xentop.c: In function 'print':
> | xentop.c:304:4: error: 'vwprintw' is deprecated
> [-Werror=deprecated-declarations]
> | vwprintw(stdscr, (curses_str_t)fmt, args);
> | ^~~~
>
> vw_printw (note
On 1/25/19 11:33 AM, Wei Liu wrote:
> On Thu, Jan 24, 2019 at 05:48:27PM +0000, George Dunlap wrote:
>> Remove "chatty" and redundant information from the xl man page;
>> restrict it to functional descriptions only, and point instead to
>> qemu-depriv.pan
On 1/24/19 11:44 AM, Wei Liu wrote:
> Below is a summary for a discussion on this topic between Jan and me.
I've skimmed this over and it looks reasonable. Thanks for doing this.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Tue, Jan 22, 2019 at 9:17 AM Jan Beulich wrote:
>
> >>> On 22.01.19 at 00:41, wrote:
> > We haven't managed to reach consensus on this topic. Your view might be
> > correct, but it is not necessarily supported by compilers' behavior,
> > which depends on the opinion of compilers engineers on
On Mon, Feb 4, 2019 at 9:37 AM Jan Beulich wrote:
>
> >>> On 01.02.19 at 19:52, wrote:
>
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In
a options.
- Re-used domain IDs are now handled.
- Device models should no longer be able to create world-readable
files on dom0's filesystem.
Signed-off-by: George Dunlap
---
RFC: I don't know what the 'vga' limitation thing was about -- I tried
both 'default' and 'stgvga' with dm_restrict
On 2/5/19 9:33 AM, Jan Beulich wrote:
On 05.02.19 at 09:29, wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1794,7 +1794,7 @@ static void svm_do_nested_pgfault(struct vcpu *v,
>> uint64_t gpa;
>> uint64_t mfn;
>>
guess you mean "rc > 0" here? This and the comment are of course
> easy enough to adjust while committing, and with the adjustments
+1
> Reviewed-by: Jan Beulich
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 4/10/19 12:13 PM, Andrew Cooper wrote:
> On 10/04/2019 11:58, Jan Beulich wrote:
>> There's no need to execute any instructions for doing so.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> I wonder whether mem_sharing_init() shouldn't go away altogether then.
>
> I vote for removing it
On 4/10/19 11:58 AM, Jan Beulich wrote:
> There's no need to execute any instructions for doing so.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpr
On 4/11/19 1:17 PM, Alexandru Stefan ISAILA wrote:
>>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>>> index b9bbb8f485..d38d7c29ca 100644
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -2626,6 +2626,7 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned
A-242
> recommendation of not calling _put_page_type while also holding the page_lock
> for that page.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Wei Liu
> Cc: Roger Pau Monne
> ---
> v2: Add assert th
) is also called in p2m_set_suppress_ve()
> because on a new altp2m view the function will fail with invalid mfn if
> p2m->set_entry() was not called before.
>
> Signed-off-by: Alexandru Isaila
> Signed-off-by: George Dunlap
Thanks for doing the expanded description; much bette
> On Apr 15, 2019, at 4:31 PM, Tamas K Lengyel wrote:
>
> On Mon, Apr 15, 2019 at 9:21 AM George Dunlap
> wrote:
>>
>> On 4/12/19 8:47 PM, Tamas K Lengyel wrote:
>>> Patch 0502e0adae2 "x86: correct instances of PGC_allocated clearing"
>>>
On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap
> wrote:
>>
>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
>>> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
>>> wrote:
>>>>
>>>> The
affect so the core function get_altp2m_entry() is calling
>> __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.
>>
>> altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
>> because on a new altp2m view the function will fail with invalid mfn if
>&g
On 4/16/19 2:51 PM, Andrew Cooper wrote:
> On 16/04/2019 14:44, Tamas K Lengyel wrote:
>>
>>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>>> index 2801a8ccca..8dc4353645 100644
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -514,6 +514,23 @@
On 4/17/19 7:22 PM, Tamas K Lengyel wrote:
> On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
> wrote:
>>
>>
>>
>> On 16.04.2019 18:07, George Dunlap wrote:
>>> On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
>>>> On Tue, Apr 16, 2019 at 8:02
On 4/18/19 2:52 AM, Daniel P. Smith wrote:
> This deals with two casting issues for compiling under go 1.11:
> - explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
> - add cast to unsafe.Pointer for the C string cpath
>
> Signed-off-by: Daniel P. Smith
Reviewed-by
On 4/18/19 2:59 PM, Tamas K Lengyel wrote:
> On Thu, Apr 18, 2019 at 3:53 AM George Dunlap
> wrote:
>>
>> On 4/17/19 7:22 PM, Tamas K Lengyel wrote:
>>> On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
>>> wrote:
>>>>
>>>>
>&
> On Mar 8, 2019, at 7:11 AM, Jan Beulich wrote:
>
>>>> George Dunlap 03/07/19 1:02 PM >>>
>> On 3/7/19 10:34 AM, Jan Beulich wrote:
>>> While I've not observed this myself, gcc 9 (imo validly) reportedly may
>>> complain
>>>
>
to maintain the fiction until such time as we decide to get rid
of it entirely.
Signed-off-by: Tamas K Lengyel
Signed-off-by: George Dunlap
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
---
xen/arch/x86/hvm/hvm.c| 19 +---
xen/arch/x86/mm/p2
callers.
>
> Signed-off-by: Juergen Gross
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
of the 64-bit case
> (real and virtual modes don't allow VEX-encoded insns). Subsequently
> _get_fpu() would then assert that CR0.PE must be set (and EFLAGS.VM
> clear) when trying to invoke YMM, ZMM, or OPMASK state.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
Tha
to maintain the fiction until such time as we decide to get rid
of it entirely.
Signed-off-by: Tamas K Lengyel
Signed-off-by: George Dunlap
---
This is identical to the patch I sent in response to Tamas' v2
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger Pau Monne
Cc: George Dunlap
> On Jun 4, 2019, at 1:44 AM, Baodong Chen wrote:
>
> Xen internal running status(trace event) will be saved to
> trace memory when enabled. trace event data and config params can be
> read/changed by system control hypercall at run time.
>
> Can be disabled for smaller code footprint.
>
>
r.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Razvan Cojocaru
> Reviewed-by: Jan Beulich
Noticed this when reviewing Tamas’ patch — thanks:
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
> On Jun 5, 2019, at 2:27 AM, Baodong Chen wrote:
>
> Xen internal running status(trace event) will be saved to
> trace memory when enabled. trace event data and config params can be
> read/changed by system control hypercall at run time.
>
> Can be disabled for smaller code footprint.
>
>
> On May 30, 2019, at 3:15 PM, Andrii Anisov wrote:
>
> From: Andrii Anisov
>
> The structure member last_run_time is used by credit scheduler only.
> So move it from a generic vcpu structure to the credit scheduler private
> vcpu definition.
This seems like a useful change, and the commit
> On May 31, 2019, at 12:10 PM, Jan Beulich wrote:
>
On 30.05.19 at 12:17, wrote:
>> Default: enabled.
>> Can be disabled for smaller code footprint.
>
> But you're aware that we're, for now at least, trying to limit the
> number of independently selectable config options? Ones
e:
xen/sched_null: Superficial clean-ups
Then just list both in bullet points; something like:
* Remove unused dependency ‘keyhandler.’h
* Make sched_null_def static
Would you mind re-sending the patch? You can add:
Reviewed-by: George Dunlap
Thanks,
-George
___
On 5/29/19 5:27 PM, Julien Grall wrote:
> Hi George,
>
> On 24/05/2019 17:24, George Dunlap wrote:
>> On 5/10/19 2:21 PM, Jan Beulich wrote:
>>>> @@ -1099,19 +1100,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
>>>>
On 5/29/19 5:23 AM, Andrew Cooper wrote:
> Drop introduced trailing whitespace, excessively long lines, mal-indention,
> superfluous use of PRI macros for int-or-smaller types, and incorrect PRI
> macros for gfns and mfns.
>
> Signed-off-by: Andrew Cooper
Acked-by: George Dunla
te-physmap, and
> decrease-reservation) are already fine due to a suitable check in
> do_memory_op().
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 5/20/19 4:13 PM, Julien Grall wrote:
> Hi,
>
> On 10/05/2019 14:25, Julien Grall wrote:
>>
>>
>> On 10/05/2019 14:24, Jan Beulich wrote:
>> On 10.05.19 at 15:02, wrote:
>>>
On 10/05/2019 12:35, Jan Beulich wrote:
On 07.05.19 at 17:14, wrote:
>> ---
On 4/1/19 8:42 AM, Jan Beulich wrote:
> Don't enforce any other dependencies for now, just like we don't enforce
> e.g. PAE enabled as a prereq for long mode.
>
> Signed-off-by: Jan Beulich
Acked-by: George Dunlap
___
Xen-devel mailing li
On 6/11/19 2:35 AM, Baodong Chen wrote:
> 'struct scheduler' already has member 'opt_name' and 'sched_id',
> thus 'name' is a little redundant, so remove it.
>
> Signed-off-by: Baodong Chen
It's not redundant; one is a longer-form human-readable description,
another is a shorthand "option"
On 6/11/19 10:20 AM, Baodong Chen wrote:
> * Remove redundant set 'DOMDYING_dead'
> domain_create() will set this when fail, thus no need
> set in arch_domain_create().
>
> * Set error when really happened
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 86341bc..d6cdcf8
On 6/11/19 10:41 AM, Jan Beulich wrote:
On 11.06.19 at 11:27, wrote:
>> Hi Jan,
>>
>> On 6/11/19 7:43 AM, Jan Beulich wrote:
>> On 10.06.19 at 22:03, wrote:
Hi,
On 6/5/19 5:01 PM, Julien Grall wrote:
> On 05/06/2019 16:58, Jan Beulich wrote:
>> Julien,
>>
On 6/13/19 11:56 AM, Alexandru Stefan ISAILA wrote:
>
>
> On 26.09.2018 19:47, George Dunlap wrote:
>> From: Isaila Alexandru
>>
>> This patch adds access control for NPT mode.
>>
>> There aren’t enough extra bits to store the access rights in the N
d for smaller code footprint.
>
> Signed-off-by: Baodong Chen
Tracing bits
Acked-by: George Dunlap https://lists.xenproject.org/mailman/listinfo/xen-devel
On 5/9/19 12:16 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH] MAINTAINERS: Add explicit check-in policy
> section"):
>> +Check-in policy
>> +===
>> +
>> +In order for a patch to be checked in, in general, several conditions
On 5/9/19 6:32 AM, Juergen Gross wrote:
> On 08/05/2019 18:24, George Dunlap wrote:
>> On 5/6/19 7:56 AM, Juergen Gross wrote:
>>> Instead of using the SCHED_OP() macro to call the different scheduler
>>> specific functions add inline wrappers for that purpose.
>>&
w.
> ---
> TBD: I wonder whether the function shouldn't gain an early tb_init_done
> check, like many other trace_*() have.
Yeah, avoiding these memcopies when tracing is not enabled seems like a
good thing.
Either way:
Acked-by: George Dunlap
>
> George, despite your
On 3/5/19 1:26 PM, Jan Beulich wrote:
> There are currently three more or less different checks:
> - _get_page_type() adjusts the IOMMU mappings according to the new type
> alone,
> - arch_iommu_populate_page_table() wants just the type to be
> PGT_writable_page,
> - iommu_hwdom_init()
ASSERTs,
thinking about ASSERT vs BUG_ON vs something else here. I guess in this
case:
1. PV guests can't be in translate mode
2. If that ever changed, we'd probably trip over the ASSERT() while
debugging
So I guess ASSERT() is probably fine.
Reviewed-by: George Dunlap
So does that m
ere's one
> more use in page_alloc.c.
>
> Signed-off-by: Jan Beulich
> Acked-by: Julien Grall
> ---
> v2: Re-base over added earlier patch. Re-write description.
Thanks:
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lis
On 5/13/19 2:47 PM, Wei Liu wrote:
> The hypervisor build system requires `python`. To avoid putting too
> much (confusing) information in README, mandate availability of
> `python`.
>
> Signed-off-by: Wei Liu
> ---
> README | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/README
On 5/10/19 7:28 PM, Andrew Cooper wrote:
> This is mostly to simplify future logical changes, but it does come with a
> modest redunction in compiled code size (-55, 345 => 290).
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Revie
On 5/9/19 2:44 PM, Jan Beulich wrote:
> Lift its !paging_mode_translate() part into guest_physmap_add_page()
> (which is what common code calls), eliminating the dummy use of a
> (HVM-only really) P2M type in the PV case.
>
> Suggested-by: George Dunlap
> Signed-off-by: Ja
rcall handling, and clarify things in the
> public header accordingly.
>
> Take the liberty and also replace a pointless use of "current" with a
> more efficient use of an existing local variable (or function parameter
> to be precise).
>
> Signed-off-by: Jan Beulich
On 5/9/19 2:42 PM, Jan Beulich wrote:
> #define-ing them to zero allows better code generation in this case,
> and paves the way for more DCE, allowing to leave certain functions just
> declared, but not defined.
>
> Signed-off-by: Jan Beulich
Reviewed-by
On 5/15/19 7:53 AM, Wei Liu wrote:
> On Tue, May 14, 2019 at 07:13:57PM +0300, Razvan Cojocaru wrote:
>> All its callers live inside #ifdef CONFIG_HVM sections.
>>
>> Signed-off-by: Razvan Cojocaru
>
> Reviewed-by: Wei Li
>> ; Wei Liu ; Roger Pau Monne
>> ;
>> rcojoc...@bitdefender.com; ta...@tklengyel.com; George Dunlap
>> ; Alexandru
>> Stefan ISAILA
>> Subject: [PATCH v4 1/2] x86/emulate: Move hvmemul_linear_to_phys
>>
>> Thiis is done so hvmemul_linear_to_phys() can be
On 5/7/19 4:14 PM, Julien Grall wrote:
> No functional changes.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Jan Beulich
> Acked-by: Stefano Stabellini
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenpr
On 5/7/19 4:14 PM, Julien Grall wrote:
> No functional changes.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Jan Beulich
> Acked-by: Stefano Stabellini
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenpr
On 5/10/19 2:21 PM, Jan Beulich wrote:
>> @@ -1099,19 +1100,19 @@ long p2m_pt_audit_p2m(struct p2m_domain *p2m)
>> entry_count++;
>> continue;
>> }
>> -mfn = l1e_get_pfn(l1e[i1]);
>> -
the changes proposed in this sub-thread:
Acked-by: George Dunlap
Sorry for taking so long to get to this, and thanks for taking on this
fairly monumental task.
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 5/24/19 4:24 PM, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
ned-off-by: Julien Grall
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 5/20/19 9:05 AM, Jan Beulich wrote:
On 18.05.19 at 00:31, wrote:
>> Don't hardcode old versions of configure in the source code, instead
>> let's just use autoconf to generate them.
>>
>> Signed-off-by: Alistair Francis
>
> For the record - I strongly disagree to this unless there's a
On 5/6/19 7:56 AM, Juergen Gross wrote:
> In order to prepare core- and socket-scheduling use a new struct
> sched_item instead of struct vcpu for interfaces of the different
> schedulers.
>
> Rename the per-scheduler functions insert_vcpu and remove_vcpu to
> insert_item and remove_item to
On 5/8/19 4:16 PM, Jan Beulich wrote:
On 08.05.19 at 17:08, wrote:
>> On 5/2/19 7:58 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -841,15 +841,19 @@ guest_physmap_add_entry(struct domain *d
>>> * any guest-requested type changes
On 5/6/19 7:56 AM, Juergen Gross wrote:
> Instead of using the SCHED_OP() macro to call the different scheduler
> specific functions add inline wrappers for that purpose.
>
> Signed-off-by: Juergen Gross
This seems like a great idea. One minor comment...
> +static inline int sched_init(struct
On 5/2/19 7:58 AM, Jan Beulich wrote:
> This is what both callers of guest_physmap_add_page() in memory.c want
> (for the !paging_mode_translate() case), and it is also what both
> callers in gnttab_transfer() need (but have been lacking). The other
> (x86-specific) callers are all HVM-only, and
On 5/14/19 3:22 PM, Wei Liu wrote:
> The directory is created by Visual Studio Code editor to store its
> local state.
>
> Signed-off-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproje
On 5/14/19 3:22 PM, Wei Liu wrote:
> The same sentence is repeated in the next paragraph.
>
> Signed-off-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/lis
On Mon, May 13, 2019 at 11:25 AM Steven Haigh wrote:
>
> There seems to be some changes in Fedora 30 that cause the second boot
> entry in grub.cfg to be booted instead of the first.
>
> This means that Fedora 30 systems either always boot into an older
> kernel, or in the case of systems with
On 4/30/19 4:06 PM, Jan Beulich wrote:
On 30.04.19 at 16:43, wrote:
>> On 4/30/19 9:44 AM, Jan Beulich wrote:
>> On 30.04.19 at 10:28, wrote:
On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
> I've outlined a solution already: Make a mem-sharing private variant
> of
On 5/1/19 11:46 AM, Ian Jackson wrote:
> These releases are out of security support. They are known not to
> build on Debian stretch, which is what we are using, and we do not
> intend to ever update them to fix that.
>
> Xen 4.6 is also out of security support but we want osstest to be able
>
On 4/8/19 12:09 PM, George Dunlap wrote:
> mem-set is the primary command that users will need to use and
> understand. Move it first, and clarify the wording; also specify that
> you can't set the target higher than maxmem from the domain config.
>
> mem-max is actually a pretty
Ping?
On 4/5/19 6:13 PM, George Dunlap wrote:
> With this script, once the main checks are out of the way, doing a
> release (either an RC or the final release) should mostly be a matter
> of executing a sequence of 4 commands given by the `help` function in
> this script.
>
On 4/30/19 9:44 AM, Jan Beulich wrote:
On 30.04.19 at 10:28, wrote:
>> On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
>>>
>> On 29.04.19 at 18:35, wrote:
On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
On 26.04.19 at 19:21, wrote:
>> --- a/xen/arch/x86/mm.c
On 4/29/19 4:41 PM, Tamas K Lengyel wrote:
> On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
>>
> On 26.04.19 at 19:21, wrote:
>>> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
>>> shr_handle_t sh,
>>> mem_sharing_page_unlock(secondpg);
>>>
On 4/29/19 3:49 PM, Andrew Cooper wrote:
> On 29/04/2019 15:46, George Dunlap wrote:
>> On 4/29/19 3:32 PM, George Dunlap wrote:
>>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
>>>> Calling _put_page_type while also holding the page_lock
>>>> for that page
g what they're used for or how they work?
Because...
> Signed-off-by: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Wei Liu
> Cc: Roger Pau Monne
> ---
> v3: simplified patch by keeping the additional references already in-place
> ---
On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Wei Liu
> Cc: Roger Pau Mo
On 4/29/19 3:32 PM, George Dunlap wrote:
> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
>> Calling _put_page_type while also holding the page_lock
>> for that page can cause a deadlock.
>>
>> Signed-off-by: Tamas K Lengyel
>> Cc: Jan Beulich
>> Cc: Andrew C
On 4/29/19 5:14 PM, Jan Beulich wrote:
>>>> On 29.04.19 at 18:05, wrote:
>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
>> wrote:
>>> I haven't re-grokked the code here, but assuming I was correct 2 weeks
>>> ago, if you have the BUG_ON() there, y
On 4/29/19 5:26 PM, Tamas K Lengyel wrote:
> On Mon, Apr 29, 2019 at 10:14 AM Jan Beulich wrote:
>>
>>>>> On 29.04.19 at 18:05, wrote:
>>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
>>> wrote:
>>>> I haven't re-grokked the code here, bu
On 4/29/19 4:18 PM, Jan Beulich wrote:
On 26.04.19 at 19:21, wrote:
>> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
>> put_page_type
>> ordering" added extra sanity checking to page_lock/page_unlock for debug
>> builds
>> with the assumption that no hypervisor path
gt; + */
> +static bool_t opt_scrub_domheap = 0;
> +boolean_param("scrub_domheap", opt_scrub_domheap);
I'm sure Jan will request this to be 'scrub-domheap' instead (not using
'_' when you can use '-').
Otherwise this looks good to me:
Acked-by: George Dunlap
I think both of these c
On 5/7/19 11:03 AM, Jan Beulich wrote:
On 07.05.19 at 11:55, wrote:
>> On 5/6/19 1:46 PM, Eslam Elnikety wrote:
>> [...]
>> I'm wondering if this should default to 'true', and people who really
>> want the extra performance should turn it off.
>
> Why would we want to cater for buggy guests
On 5/2/19 7:58 AM, Jan Beulich wrote:
> This is what both callers of guest_physmap_add_page() in memory.c want
> (for the !paging_mode_translate() case), and it is also what both
> callers in gnttab_transfer() need (but have been lacking). The other
> (x86-specific) callers are all HVM-only, and
On 5/7/19 1:11 PM, Jan Beulich wrote:
On 07.05.19 at 13:34, wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -214,6 +214,10 @@ custom_param("bootscrub", parse_bootscrub_param);
>> static unsigned long __initdata opt_bootscrub_chunk = MB(128);
>>
On Fri, May 3, 2019 at 1:55 PM Mathieu Tarral
wrote:
>
> Hi,
>
> As stated by the documentation:
> "_Xen Project downloads various dependencies at build time_"
>
> This makes Xen a difficult project to work with in an offline environment.
There are lots of people who would like to see this
On 10/18/18 4:20 PM, George Dunlap wrote:
> On 10/12/2018 03:19 PM, Jan Beulich wrote:
>>>>> On 12.10.18 at 15:55, wrote:
>>> On 11/09/18 14:10, Jan Beulich wrote:
>>>> Emulation requiring device model assistance uses a form of instruction
>>>&
801 - 900 of 1989 matches
Mail list logo
