flight 130611 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130611/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Wed, 2018-11-21 at 15:57 +, George Dunlap wrote:
> On 10/11/18 2:44 PM, Dario Faggioli wrote:
> >
> Reviewed-by: George Dunlap
>
> One comment: The title seems to have excessive tags. You only need
> enough for people scrolling through to figure out the domain;
> "xen/credit2:", or even
On Wed, Nov 21, 2018 at 2:22 PM Andrew Cooper wrote:
>
> On 21/11/2018 17:19, Tamas K Lengyel wrote:
> > On Wed, Nov 21, 2018 at 6:21 AM Andrew Cooper
> > wrote:
> >> This covers various fixes related to XSA-277 which weren't in security
> >> supported areas, and associated cleanup.
> >>
> >>
On 11/16/18 7:04 PM, Roger Pau Monné wrote:
>> +if ( a == v )
>> +continue;
>> +
>> +/* Pause, synced. */
>> +while ( !a->arch.in_host )
> Why not use a->is_running as a way to know whether the vCPU is
> running?
>
> I think the logic of using
* Some of the single-byte versions specify "=q" as the output. AFAICT, there
was not a legitimate reason to restrict the use of %esi/%edi in the 32-bit
build. Either way, in 64-bit, it is equivelent to "=r".
* Constraints in the form "=r" (x) : "0" (x) can be folded to just "+r" (x)
*
flight 130628 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
Hi Igor,
On Wed, Nov 14, 2018 at 11:55:37AM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:34 +0100
> Samuel Ortiz wrote:
>
> > From: Yang Zhong
> >
> > The AML build routines for the PCI host bridge and the corresponding
> > DSDT addition are neither x86 nor PC machine type
On 11/21/18 2:56 PM, Souptick Joarder wrote:
> On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
> wrote:
>> On 11/21/18 1:24 AM, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder
>>> wrote:
Previouly drivers have their own way of mapping range of
kernel
flight 130661 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130661/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6
On 21/11/2018 17:19, Tamas K Lengyel wrote:
> On Wed, Nov 21, 2018 at 6:21 AM Andrew Cooper
> wrote:
>> This covers various fixes related to XSA-277 which weren't in security
>> supported areas, and associated cleanup.
>>
>> The biggest issue noticed here is that altp2m's use of hardware #VE
On 11/21/18 1:24 AM, Souptick Joarder wrote:
> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote:
>> Previouly drivers have their own way of mapping range of
>> kernel pages/memory into user vma and this was done by
>> invoking vm_insert_page() within a loop.
>>
>> As this pattern is common
flight 130666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130666/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6
On Thu, Nov 15, 2018 at 02:28:54PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:38 +0100
> Samuel Ortiz wrote:
>
> > This is the standard way of building SRAT on x86 platfoms. But future
> > machine types could decide to define their own custom SRAT build method
> > through the ACPI
On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
wrote:
>
> On 11/21/18 1:24 AM, Souptick Joarder wrote:
> > On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder
> > wrote:
> >> Previouly drivers have their own way of mapping range of
> >> kernel pages/memory into user vma and this was done by
> >>
Hi Igor,
On Thu, Nov 15, 2018 at 01:36:58PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:35 +0100
> Samuel Ortiz wrote:
>
> > From: Yang Zhong
> >
> > The ACPI MCFG getter is not x86 specific and could be called from
> > anywhere within generic ACPI API, so let's export it.
> So
On 11/21/18 12:45 PM, Jan Beulich wrote:
On 21.11.18 at 11:19, wrote:
>> +static int p2m_activate_altp2m(struct domain *d, unsigned int idx)
>> +{
>> +struct p2m_domain *hostp2m, *p2m;
>> +int rc;
>> +
>> +ASSERT(idx < MAX_ALTP2M);
>> +
>> +p2m = d->arch.altp2m_p2m[idx];
>> +
>>> On 21.11.18 at 11:37, wrote:
> On Wed, Nov 21, 2018 at 02:21:36AM -0700, Jan Beulich wrote:
>> >>> On 21.11.18 at 00:26, wrote:
>> > The original commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
>> >
>> > The commit that adds is_hardware_domain (and rearrange things)
>> >
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/mem_access.c | 2 +-
xen/include/asm-x86/mem_access.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 30c2f1a..56c06a4 100644
---
Could you add a line to the description explicitly stating that a failure
to insert any page in the range will fail the entire routine, something
like:
> * This allows drivers to insert range of kernel pages they've allocated
> * into a user vma. This is a generic function which drivers can use
>
>>> On 21.11.18 at 11:57, wrote:
> On 11/21/18 12:49 PM, Jan Beulich wrote:
> On 21.11.18 at 11:19, wrote:
>>> Refactor p2m_reset_altp2m() so that it can be used to remove
>>> redundant codepaths, fixing the locking while we're at it.
>>
>> Still no word about ...
>>
>>> +static void
>>> On 21.11.18 at 12:03, wrote:
> On 11/21/18 11:01 AM, Razvan Cojocaru wrote:
>> Signed-off-by: Razvan Cojocaru
>
> Why?
Are you asking in general (I think it's obvious), or merely because
the commit description is empty?
Jan
___
Xen-devel
On Wed, Nov 21, 2018 at 03:58:34AM -0700, Jan Beulich wrote:
> >>> On 21.11.18 at 11:37, wrote:
> > On Wed, Nov 21, 2018 at 02:21:36AM -0700, Jan Beulich wrote:
> >> >>> On 21.11.18 at 00:26, wrote:
> >> > The original commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
> >> >
> >> > The commit
On 11/21/18 1:52 PM, George Dunlap wrote:
> On 11/21/18 11:41 AM, Jan Beulich wrote:
> On 21.11.18 at 12:03, wrote:
>>> On 11/21/18 11:01 AM, Razvan Cojocaru wrote:
Signed-off-by: Razvan Cojocaru
>>>
>>> Why?
>>
>> Are you asking in general (I think it's obvious), or merely because
>>
On 15/11/2018 10:36, Roger Pau Monné wrote:
> On Fri, Nov 02, 2018 at 01:37:30PM +0100, Juergen Gross wrote:
>> Retrieve the memory map from the hypervisor and normalize it to contain
>> no overlapping entries and to be sorted by address.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> V3: use
On 21.11.18 07:04, Baoquan He wrote:
> On 11/19/18 at 11:16am, David Hildenbrand wrote:
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 933cb3e45b98..093c9f917ed0 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -464,6 +464,8 @@ static int __init
On 14/11/2018 13:48, Roger Pau Monné wrote:
> On Fri, Nov 02, 2018 at 01:37:31PM +0100, Juergen Gross wrote:
>> Add possible PCI space MMIO areas as "Reserved" to the memory map in
>> order to avoid using those areas for special Xen pages later.
>
> TBH, I'm not sure this is the best way to solve
flight 130641 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-amd64 6
On 11/21/18 12:00 PM, Jan Beulich wrote:
On 20.11.18 at 19:05, wrote:
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -541,6 +541,11 @@ void arch_p2m_set_access_required(struct domain *d,
>> bool access_required)
>> #endif
>> }
>>
>> +bool
>>> On 21.11.18 at 11:19, wrote:
> Refactor p2m_reset_altp2m() so that it can be used to remove
> redundant codepaths, fixing the locking while we're at it.
Still no word about ...
> +static void p2m_reset_altp2m(struct domain *d, unsigned int idx,
> + enum
On 11/21/18 12:49 PM, Jan Beulich wrote:
On 21.11.18 at 11:19, wrote:
>> Refactor p2m_reset_altp2m() so that it can be used to remove
>> redundant codepaths, fixing the locking while we're at it.
>
> Still no word about ...
>
>> +static void p2m_reset_altp2m(struct domain *d, unsigned int
On 11/21/18 11:01 AM, Razvan Cojocaru wrote:
> Signed-off-by: Razvan Cojocaru
Why?
-George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 21.11.2018 13:41, Roger Pau Monné wrote:
> On Wed, Nov 21, 2018 at 10:28:18AM +, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 21.11.2018 11:56, Roger Pau Monné wrote:
>>> On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
On 19.11.2018 17:08, Roger Pau Monné
flight 130549 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130549/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
On 20/11/2018 18:09, Wei Liu wrote:
> Introduce XEN_DOM0_UUID in Xen's global configuration file. Make
> xen-init-dom0 accept an extra argument for UUID.
>
> Signed-off-by: Wei Liu
> ---
> v3: new approach
> ---
> tools/helpers/Makefile | 3 +-
>
On 11/21/18 12:09 PM, Razvan Cojocaru wrote:
> Minor improvement; simply improving code quality by using consts
> wherever reasonable.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Razvan Cojocaru
Reviewed-by: George Dunlap
___
Xen-devel mailing
On 15/11/2018 11:03, Roger Pau Monné wrote:
> On Fri, Nov 02, 2018 at 01:37:32PM +0100, Juergen Gross wrote:
>> Initialize the needed Xen specific data. This is:
>>
>> - the Xen start of day page containing the console and Xenstore ring
>> page PFN and event channel
>> - the grant table
>> - the
The logdirty rangesets of the altp2ms need to be kept in sync with the
hostp2m. This means when iterating through the altp2ms, we need to
use the host p2m to clip the rangeset, not the indiviual altp2m's
value.
This change also:
- Documents that the end is non-inclusive
- Calculates an
When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).
The series introduces p2m_{init,free}_logdirty(), allocates a new
logdirty rangeset for each new altp2m, and propagates (under lock)
changes
Add logdirty_ranges allocator / deallocator helpers.
p2m_init_logdirty() will not re-allocate if
p2m->logdirty ranges has already been allocated.
Move the rangeset deallocation call from p2m_teardown_hostp2m()
to p2m_free_one() - we will want this to apply to altp2ms
as well.
Signed-off-by:
change_range_type() invalidates gfn ranges to lazily change the type
of a range of gfns, and also modifies the logdirty rangesets of that
p2m. At the moment, it clips both down by the hostp2m.
While this will result in correct behavior, it's not entirely efficient,
since invalidated entries
For now, only do allocation/deallocation; keeping them in sync
will be done in subsequent patches.
Logdirty synchronization will only be done for active altp2ms;
so allocate logdirty rangesets (copying the host logdirty
rangeset) when an altp2m is activated, and free it when
deactivated.
Refactor p2m_reset_altp2m() so that it can be used to remove
redundant codepaths, fixing the locking while we're at it.
Signed-off-by: Razvan Cojocaru
---
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/mm/p2m.c | 57
If you are adding PageOffline(page) to the condition list of the already
existing if in
saveable_highmem_page(), why explicitly add it as a separate statement in
saveable_page()?
It would seem more consistent to make the second check:
- if (swsusp_page_is_forbidden(page) ||
flight 130610 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130610/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
On Wed, Nov 21, 2018 at 10:28:18AM +, Alexandru Stefan ISAILA wrote:
>
>
> On 21.11.2018 11:56, Roger Pau Monné wrote:
> > On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
> >> On 19.11.2018 17:08, Roger Pau Monné wrote:
> > Also, after looking at the code I'm not
On 11/21/18 10:49 AM, Jan Beulich wrote:
On 21.11.18 at 11:19, wrote:
>> Refactor p2m_reset_altp2m() so that it can be used to remove
>> redundant codepaths, fixing the locking while we're at it.
>
> Still no word about ...
>
>> +static void p2m_reset_altp2m(struct domain *d, unsigned int
On 11/21/18 11:41 AM, Jan Beulich wrote:
On 21.11.18 at 12:03, wrote:
>> On 11/21/18 11:01 AM, Razvan Cojocaru wrote:
>>> Signed-off-by: Razvan Cojocaru
>>
>> Why?
>
> Are you asking in general (I think it's obvious), or merely because
> the commit description is empty?
I didn't see that
Minor improvement; simply improving code quality by using consts
wherever reasonable.
Suggested-by: Jan Beulich
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/mm/mem_access.c | 2 +-
xen/include/asm-x86/mem_access.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, 20 Nov 2018 19:54:23 +0100
Laszlo Ersek wrote:
> On 11/20/18 17:33, Igor Mammedov wrote:
> > On Wed, 7 Nov 2018 16:36:40 +0400
> > Marc-André Lureau wrote:
> >
> >> Interfaces don't have instance, let's make the interface type really
> >> abstract to avoid confusion.
> >>
> >>
On 20/11/2018 17:16, Jan Beulich wrote:
On 20.11.18 at 18:00, wrote:
>> Now that idle scrub is the default option, all memory is marked as dirty
>> and alloc_domheap_pages() will do eager scrubbing by default. This can
>> lead to longer Dom0 construction and potentially to a watchdog
>>> On 20.11.18 at 19:05, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -541,6 +541,11 @@ void arch_p2m_set_access_required(struct domain *d, bool
> access_required)
> #endif
> }
>
> +bool p2m_mem_access_sanity_check(struct domain *d)
> +{
> +
On 11/20/18 17:37, Andrew Cooper wrote:
> On 20/11/2018 15:49, Jan Beulich wrote:
> On 20.11.18 at 16:37, wrote:
>>> To mitigate Meltdown, Xen has been fixed with a software fix, namely
>>> using retpoline sequences generated by the compiler. This way, indirect
>>> branches are protected
flight 130609 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130609/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
On 21/11/2018 10:05, Norbert Manthey wrote:
> On 11/20/18 17:37, Andrew Cooper wrote:
>> On 20/11/2018 15:49, Jan Beulich wrote:
>> On 20.11.18 at 16:37, wrote:
To mitigate Meltdown, Xen has been fixed with a software fix, namely
using retpoline sequences generated by the compiler.
On Wed, Nov 21, 2018 at 02:21:36AM -0700, Jan Beulich wrote:
> >>> On 21.11.18 at 00:26, wrote:
> > The original commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
> >
> > The commit that adds is_hardware_domain (and rearrange things)
> > 7c275549f46c5c46611592f7107c1345e93ed457
> >
> > The
>>> On 21.11.18 at 00:26, wrote:
> The original commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
>
> The commit that adds is_hardware_domain (and rearrange things)
> 7c275549f46c5c46611592f7107c1345e93ed457
>
> The orginal commit used the function like
> setup_dom0_pci_devices(d,
While in the native case entry into the kernel happens on the trampoline
stack, PV Xen kernels get entered with the current thread stack right
away. Hence source and destination stacks are identical in that case,
and special care is needed.
Other than in sync_regs() the copying done on the INT80
On 21.11.18 04:22, Nadav Amit wrote:
> Thanks for this patch!
>
>> On Nov 19, 2018, at 2:16 AM, David Hildenbrand wrote:
>>
>> Mark inflated and never onlined pages PG_offline, to tell the world that
>> the content is stale and should not be dumped.
>>
>> Cc: Xavier Deguillard
>> Cc: Nadav Amit
Signed-off-by: Razvan Cojocaru
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/include/asm-x86/p2m.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 6d849a5..b52fefd 100644
---
>>> On 20.11.18 at 18:06, wrote:
> On 20/11/2018 16:19, Jan Beulich wrote:
>> Quite a bit of duplicate code has accumulated on the "paging" types
>> special case path. Re-use what can be re-used from the common path.
>>
>> Since it needs touching anyway, slightly re-format and extend the
>>
On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
>
>
> On 19.11.2018 17:08, Roger Pau Monné wrote:
> > On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
> +/* Now transform our RWX values in a XENMEM_access_* constant. */
> +if ( r
On 21.11.2018 11:56, Roger Pau Monné wrote:
> On Mon, Nov 19, 2018 at 03:56:14PM +, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 19.11.2018 17:08, Roger Pau Monné wrote:
>>> On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
>> +/* Now transform our RWX values in
>>> On 21.11.18 at 11:19, wrote:
> +static int p2m_activate_altp2m(struct domain *d, unsigned int idx)
> +{
> +struct p2m_domain *hostp2m, *p2m;
> +int rc;
> +
> +ASSERT(idx < MAX_ALTP2M);
> +
> +p2m = d->arch.altp2m_p2m[idx];
> +hostp2m = p2m_get_hostp2m(d);
> +
> +
On Wed, Nov 21, 2018 at 04:19:11AM -0700, William Kucharski wrote:
> Could you add a line to the description explicitly stating that a failure
> to insert any page in the range will fail the entire routine, something
> like:
>
> > * This allows drivers to insert range of kernel pages they've
On Mon, Nov 19, 2018 at 04:31:10PM +0100, Igor Mammedov wrote:
> On Fri, 16 Nov 2018 17:37:54 +0100
> Paolo Bonzini wrote:
>
> > On 16/11/18 17:29, Igor Mammedov wrote:
> > > General suggestions for this series:
> > > 1. Preferably don't do multiple changes within a patch
> > > neither
get_gfn_query() internally takes the p2m lock, and this error path leaves it
locked.
This wasn't included in XSA-277 because the error path can only be triggered
by a carefully timed phymap operation concurrent with the domain being paused
and the toolstack issuing DOMCTL_soft_reset.
The gfn references need to remain held until after the p2m_set_entry() has
completed. This is only a latent bug for now, because there is no per-gfn
locking and we recursively hold the main p2m locks.
Rearrange the code to have a single exit path, and defer taking the ap2m lock
until it is
get_gfn_type_access() internally takes the p2m lock, and nothing ever unlocks
it. Switch to using the unlocked accessor instead.
This wasn't included in XSA-277 because neither mem-sharing nor altp2m are
supported.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau
The final parameter to p2m_altp2m_lazy_copy() appears to be unnecessary, and
results in very hard-to-follow code. Have the sole caller set its local p2m
pointer appropriately, and drop the parameter.
With that done, a level of indirection of ap2m can be dropped inside
p2m_altp2m_lazy_copy().
Drop the ap2m_active boolean, and consistently use the unlocking form:
if ( p2m != hostp2m )
__put_gfn(p2m, gfn);
__put_gfn(hostp2m, gfn);
which makes it clear that we always unlock the altp2m's gfn if it is in use,
and always unlock the hostp2m's gfn. This also drops the ternary
A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.
This patch adds code to do this as follows:
- an 'fd handler'
Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using error_report().
This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.
The XenBus object is instantiated by a new xen_bus_init() function called
from the same sites as the legacy
This series introduces a new QOM compliant framework for Xen PV backends.
This is achieved by first moving the current non-compliant framework aside,
before building up a new framework incrementally.
This series was prompted by a thread [1] started by Kevin Wolf in response
to patches against
On Wed, Nov 21, 2018 at 2:10 AM Jan Beulich wrote:
>
> While in the native case entry into the kernel happens on the trampoline
> stack, PV Xen kernels get entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is
...and wire in the dataplane.
This patch adds the remaining code to make the xen-qdisk XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the frontend xenstore area are
...that maintains compatibility with existing Xen toolstacks.
Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.
This patch adds a new 'xen-backend' module to allow individual XenDevice
This patch adds a creator function for XenQdiskDevice-s so that they can
be created automatically when the Xen toolstack instantiates a new
PV backend. When the XenQdiskDevice is created this way it is also
necessary to create a drive which matches the configuration that the Xen
toolstack has
This backend has now been replaced by the 'xen-qdisk' XenDevice.
Signed-off-by: Paul Durrant
---
Cc: Kevin Wolf
Cc: Max Reitz
---
hw/block/Makefile.objs |1 -
hw/block/xen_disk.c| 1011
2 files changed, 1012 deletions(-)
delete mode
This is a purely cosmetic patch that purges the name 'ioreq' from struct,
variable and field names. (This name has been problematic for a long time
as 'ioreq' is the name used for generic I/O requests coming from Xen).
The patch replaces 'struct ioreq' with a new 'XenQdiskRequest' type and
'ioreq'
This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Stefan Hajnoczi
Cc: Kevin Wolf
Cc: Max Reitz
---
hw/block/dataplane/xen-qdisk.c | 86
This patch adds the transformations necessary to get dataplane/xen-qdisk.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-qdisk.h.
NOTE: Existing data structure names are retained for the moment. These will
be
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenQdiskDataPlane' and 'blkdev' field/variable names with
'dataplane', and then does necessary fix-up to adhere to coding style.
No functional change.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing the
legacy code. It
On 21.11.18 15:58, Kazuhito Hagio wrote:
> Hi David,
>
>> Linux marks pages that are logically offline via a page flag (map count).
>> Such pages e.g. include pages infated as part of a balloon driver or
>> pages that were not actually onlined when onlining the whole section.
>>
>> While the
On Tue, Nov 13, 2018 at 04:59:18PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:33 +0100
> Samuel Ortiz wrote:
>
> > This is going to be needed by the hardware reduced implementation, so
> > let's export it.
> > Once the ACPI builder methods and getters will be implemented, the
> >
On 10/11/18 2:44 PM, Dario Faggioli wrote:
> Load balancing, when happening, at the end of a "scheduler epoch", can
> trigger vcpu migration, which in its turn may call runq_tickle(). If the
> cpu where this happens was idle, but we're now going to schedule a vcpu
> on it, let's update the runq's
The new xen-qdisk XenDevice implementation requires the same core dataplane
as the legacy xen_disk implementation it will eventually replace. This
patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-qdisk.c source module as the basis for the new dataplane and
The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
---
This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then uses
these primitives
This patch adds a new XenDevice: 'xen-qdisk' [1]. This will eventually
replace the 'xen_disk' legacy PV backend but it is illustrative to build
up the implementation incrementally, along with the XenBus/XenDevice
framework. Subsequent patches will therefore add to this device's
implementation as
On 10/11/18 2:47 PM, Dario Faggioli wrote:
> For doing load balancing between runqueues, we check the load of each
> runqueue, select the one more "distant" than our own load, and then take
> the proper runq lock and attempt vcpu migrations.
>
> If we fail to take such lock, we try again, and the
>>> On 21.11.18 at 12:51, wrote:
> On Wed, Nov 21, 2018 at 03:58:34AM -0700, Jan Beulich wrote:
>> >>> On 21.11.18 at 11:37, wrote:
>> > On Wed, Nov 21, 2018 at 02:21:36AM -0700, Jan Beulich wrote:
>> >> >>> On 21.11.18 at 00:26, wrote:
>> >> > The original commit
Now that idle scrub is the default option, all memory is marked as dirty
and alloc_domheap_pages() will do eager scrubbing by default. This can
lead to longer Dom0 construction and potentially to a watchdog timeout,
especially on older H/W (e.g. Harpertown).
Pass MEMF_no_scrub to optimise this
Initialize the grant tab in a dedicated function. This will enable
using it for PVH guests, too.
Call the new function from grub_machine_init() as this will later
be common between Xen PV and Xen PVH mode.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
V2: update commit message
Add all usable memory regions to grub memory management and add the
needed mmap iterate code, which will be used by grub core (e.g.
grub-core/lib/relocator.c or grub-core/mmap/mmap.c).
As we are running in 32-bit mode don't add memory above 4GB.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel
In order to avoid using plain integers for the ELF notes use the
available Xen include instead.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
V5: new patch (Daniel Kiper)
---
util/grub-mkimagexx.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
Hi Igor,
On Fri, Nov 09, 2018 at 03:23:16PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:24 +0100
> Samuel Ortiz wrote:
>
> > ACPI tables are platform and machine type and even architecture
> > agnostic, and as such we want to provide an internal ACPI API that
> > only depends on
>>> On 21.11.18 at 15:13, wrote:
> Now that idle scrub is the default option, all memory is marked as dirty
> and alloc_domheap_pages() will do eager scrubbing by default. This can
> lead to longer Dom0 construction and potentially to a watchdog timeout,
> especially on older H/W (e.g.
1 - 100 of 171 matches
Mail list logo
