>>> On 04.09.18 at 18:15, wrote:
> @@ -675,6 +678,100 @@ static inline bool altp2m_vcpu_emulate_ve(struct vcpu
> *v)
> d_->arch.hvm.pi_ops.vcpu_block(v_); \
> })
>
> +#else /* CONFIG_HVM */
> +
> +#define hvm_enabled false
> +
> +/*
> + * List of inline functions
>>> On 04.09.18 at 18:15, wrote:
> @@ -149,6 +149,7 @@ static void p2m_teardown_hostp2m(struct domain *d)
> }
> }
>
> +#ifdef CONFIG_HVM
> static void p2m_teardown_nestedp2m(struct domain *d)
> {
> unsigned int i;
> @@ -186,6 +187,7 @@ static int p2m_init_nestedp2m(struct domain *d)
>>> On 04.09.18 at 18:15, wrote:
> --- a/xen/arch/x86/mm/Makefile
> +++ b/xen/arch/x86/mm/Makefile
> @@ -1,15 +1,16 @@
> subdir-y += shadow
> -subdir-y += hap
> +subdir-$(CONFIG_HVM) += hap
>
> -obj-y += paging.o
> -obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
> -obj-y += altp2m.o
> +obj-$(CONFI
>>> On 04.09.18 at 18:15, wrote:
> Signed-off-by: Wei Liu
> ---
> v3: longer text
> v2: use tab to indent
>
> Haven't added a dependency on PV_SHIM_EXCLUSIVE because agreement is
> not yet reached.
Hmm, but then I would have expected you to at least do the minimal
agreed upon change (modifying
On Fri, Sep 07, 2018 at 12:19:29AM +0200, Valentin Vidic wrote:
> On Thu, Sep 06, 2018 at 06:29:32PM +0200, Roger Pau Monné wrote:
> > On Wed, Sep 05, 2018 at 06:28:01PM +0200, Valentin Vidic wrote:
> > > On Wed, Sep 05, 2018 at 01:35:15PM +0200, Valentin Vidic wrote:
> > > > > AFAICT, this will ca
flight 127344 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 125898
>>> On 04.09.18 at 18:15, wrote:
> Signed-off-by: Wei Liu
> Reviewed-by: Roger Pau Monné
I think this should be merged into the previous patch, no matter what
the final resolution there is, as even with the change of default the
adjustment here should happen. Otoh Roger's "pvshim: introduce a P
On Fri, Sep 07, 2018 at 09:15:30AM +0200, Roger Pau Monné wrote:
> I'm not sure that's a good idea, there are a lot of backends (apart
> from blkback), and the tools won't know whether a specific backend
> supports such state or not. Also the current protocol and states are
> shared between all the
flight 127361 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 127357
Tests which did not succee
>>> On 06.09.18 at 14:08, wrote:
> The format identifier is consistent with Linux. The code is adapted from
> bitmap_scn{,list}printf() but cleaned up.
Irrespective of this I'm somewhat worried by ...
> --- a/docs/misc/printk-formats.txt
> +++ b/docs/misc/printk-formats.txt
> @@ -13,6 +13,14 @@
On Fri, Sep 07, 2018 at 01:18:52AM -0600, Jan Beulich wrote:
> >>> On 04.09.18 at 18:15, wrote:
> > Signed-off-by: Wei Liu
> > Reviewed-by: Roger Pau Monné
>
> I think this should be merged into the previous patch, no matter what
> the final resolution there is, as even with the change of defau
On Fri, Sep 07, 2018 at 08:46:34AM +0100, Wei Liu wrote:
> On Fri, Sep 07, 2018 at 01:18:52AM -0600, Jan Beulich wrote:
> > >>> On 04.09.18 at 18:15, wrote:
> > > Signed-off-by: Wei Liu
> > > Reviewed-by: Roger Pau Monné
> >
> > I think this should be merged into the previous patch, no matter w
On 07/09/18 08:30, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-
On Fri, Sep 07, 2018 at 09:23:19AM +0200, Valentin Vidic wrote:
> On Fri, Sep 07, 2018 at 09:15:30AM +0200, Roger Pau Monné wrote:
> > I'm not sure that's a good idea, there are a lot of backends (apart
> > from blkback), and the tools won't know whether a specific backend
> > supports such state o
>>> On 06.09.18 at 14:08, wrote:
> @@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int cpu)
> spc = CSCHED_PCPU(cpu);
> runq = &spc->runq;
>
> -cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask,
> cpu));
> -printk("CPU[%02d] nr_run=%d, so
flight 127350 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127350/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 127280
test-armhf-armhf-libvirt-raw 13 save
>>> On 06.09.18 at 14:08, wrote:
> This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
> string. In some cases, collapse combine adjacent printk()'s which are writing
> parts of the same line.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Subject to pos
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 07:24
> To: Paul Durrant ; Kevin Tian
>
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Stefano Stabellini ; xen-
> devel
> Subject: RE: [Xen-devel] [PATCH v6 01/14] iommu: introduce the concept o
>>> On 06.09.18 at 14:08, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -535,9 +535,12 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
> mc_panic("MCE: No CPU found valid MCE, need reset");
> if ( !cpumask_empty(&mce_fata
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Friday, September 7, 2018 4:13 PM
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 07 September 2018 07:24
> > To: Paul Durrant ; Kevin Tian
> >
> > Cc: Suravee Suthikulpanit ; Julien Grall
>
>>> On 06.09.18 at 14:08, wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -489,7 +489,7 @@ static EFI_FILE_HANDLE __init
> get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
> static EFI_GUID __initdata fs_protocol = SIMPLE_FILE_SYSTEM_PROTOCOL;
> EFI_FILE_HANDLE
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 07 September 2018 09:17
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Stefano Stabellini ; xen-
> devel
> Subject: RE: [Xen-devel] [PATCH v6 01/14] iommu: introduce the con
On 06/09/18 14:08, Andrew Cooper wrote:
> This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
> string. In some cases, collapse combine adjacent printk()'s which are writing
> parts of the same line.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by
>>> On 06.09.18 at 16:01, wrote:
> alloc_vcpu()'s call to domain_update_node_affinity() has existed for a decade,
> but its effort is mostly wasted.
>
> alloc_vcpu() is called in a loop for each vcpu, bringing them into existence.
> The values of the affinity masks are still default, which is all
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 06 September 2018 19:12
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabel
On Thu, Sep 06, 2018 at 03:01:35PM +0100, Andrew Cooper wrote:
> alloc_vcpu()'s call to domain_update_node_affinity() has existed for a decade,
> but its effort is mostly wasted.
>
> alloc_vcpu() is called in a loop for each vcpu, bringing them into existence.
> The values of the affinity masks ar
>>> On 05.09.18 at 21:15, wrote:
> Since its introduction in c/s 8cbb5278e "x86/AMD: Add support for AMD's OSVW
> feature in guests", the OSVW data has been corrected to be per-domain rather
> than per-vcpu, and is initialised during XEN_DOMCTL_createdomain.
>
> Furthermore, because XENPF_microco
>>> On 06.09.18 at 17:21, wrote:
> On 06/09/18 09:56, Paul Durrant wrote:
>>> @@ -4390,9 +4411,6 @@ static int hvmop_get_param(
>>> if ( copy_from_guest(&a, arg, 1) )
>>> return -EFAULT;
>>>
>>> -if ( a.index >= HVM_NR_PARAMS )
>>> -return -EINVAL;
>>> -
>> ASSERT, just i
Hello,
The following series implement a workaround for missing RMRR
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option.
The PVH workaround identity maps all regions marked as reserved in the
memory map.
Note that this workaround is enabled by default on Intel hardware.
Returns all the memory types applicable to a page.
This function is unimplemented for ARM.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v7:
- Switch the parameter type to mfn_t.
Changes since v5:
- Return all types that apply to a page, since the types themselves
This avoids repeated calls to page_is_ram_type which improves
performance and makes the code easier to read.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
Changes since v7:
- Switch to use mfn_t with page_get_ram_type.
Changes since v4:
- New in this versio
>>> On 06.09.18 at 11:26, wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 05 September 2018 19:12
>>
>> The parameter marshalling and xsm checks are common to both the set and
>> get
>> paths. Lift all of the common code out into do_hvm_op() and let
>> hvmop_{get,set}_p
To select the iommu configuration used by Dom0. This option supersedes
iommu=dom0-strict|dom0-passthrough.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
Changes since v5:
- Fix typo in docs.
- Force iommu_hwdom_passthrough to false for PVH Dom0. Note this in
To iommu_hwdom_strict and iommu_hwdom_passthrough which is more
descriptive of their usage. Also change their type from bool_t to
bool.
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Co
Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults on Intel hardware. Those faults
are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
be worked around on VTd hardware by manually adding RMRR entries on
the command line, this is
Introduce a new dom0-iommu=map-inclusive generic option that
supersedes iommu_inclusive_mapping. The previous behavior is preserved
and the option should only be enabled by default on Intel hardware.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Reviewed-by: Jan Beulich
Reviewed-by:
flight 127359 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On Thu, Sep 06, 2018 at 11:37:28AM +0100, Wei Liu wrote:
> On Tue, Jul 17, 2018 at 11:48:30AM +0200, Roger Pau Monne wrote:
> > +curr->vpci.wait.callback = enable_callback;
> > +curr->vpci.wait.data = cb;
> > +curr->vpci.wait.end = get_cycles() + 100 * cpu_khz;
>
tools/tests/depriv/Makefile directly builds the target program from
its C-source. This is problematic when an incremental build is needed
after a header the program is depending on has been modified: in this
case all headers are added into the gcc call and the build will fail.
Correct that by addi
>>> On 03.09.18 at 15:14, wrote:
> This patch is aimed on using the new save_one fuctions in the hvm_save
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
Am Fri, 7 Sep 2018 09:48:28 +0200
schrieb Juergen Gross :
> On 07/09/18 08:30, Olaf Hering wrote:
> > + if (cpu_online(cpu))
> > + return;
> > if (cpu_present(cpu))
> > xen_arch_unregister_cpu(cpu);
> Could you merge the two if conditions?
> if (!cpu_online(cpu) && c
>>> On 03.09.18 at 15:14, wrote:
> This patch removes the redundant save functions and renames the
> save_one* to save. It then changes the domain param to vcpu in the
> save funcs and adapts print messages in order to match the format of the
> other save related messages.
>
> Signed-off-by: Alex
>>> On 03.09.18 at 15:14, wrote:
> This patch is focused on moving changing hvm_save_one() to save one
> typecode from one vcpu and now that the save functions get data from a
> single vcpu we can pause the specific vcpu instead of the domain.
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Ja
>>> On 03.09.18 at 15:14, wrote:
> This patch series addresses the ideea of saving data from a single vcpu
> instance.
> First it starts by adding *save_one functions, then it introduces a handler
> for the
> new save_one* funcs and makes use of it in the hvm_save and hvm_save_one
> funcs.
> Th
On 07/09/18 11:24, Olaf Hering wrote:
> Am Fri, 7 Sep 2018 09:48:28 +0200
> schrieb Juergen Gross :
>
>> On 07/09/18 08:30, Olaf Hering wrote:
>>> + if (cpu_online(cpu))
>>> + return;
>>> if (cpu_present(cpu))
>>> xen_arch_unregister_cpu(cpu);
>
>> Could you merge th
>>> On 06.09.18 at 21:25, wrote:
> The vcpu functions are far less consistent than the domain side of things, and
> in particular, has vcpu_destroy() for architecture specific functionality.
>
> Perform the following renames:
>
> * alloc_vcpu => vcpu_create
> * vcpu_initialise => arch_v
>>> On 06.09.18 at 21:25, wrote:
> Like _domain_destroy(), this will eventually idempotently free all parts of a
> struct vcpu.
>
> While breaking apart the failure path of vcpu_create(), rework the codeflow to
> be in a line at the end of the function for clarity.
>
> Signed-off-by: Andrew Coop
On 07/09/18 09:48, Jan Beulich wrote:
On 05.09.18 at 21:15, wrote:
>> Since its introduction in c/s 8cbb5278e "x86/AMD: Add support for AMD's OSVW
>> feature in guests", the OSVW data has been corrected to be per-domain rather
>> than per-vcpu, and is initialised during XEN_DOMCTL_createdomai
>>> On 06.09.18 at 21:25, wrote:
> While v0 must be the first allocated vcpu for for_each_vcpu() to work, it
> isn't a requirement for the threading the vcpu into the linked list, so update
> the threading code to be more generic, and add a comment explaining why we
> need to search for prev_id.
On Fri, Sep 07, 2018 at 09:54:55AM +0200, Roger Pau Monné wrote:
> Then I'm afraid you will have to look into the vbd_free/create fix.
Yes, here is a first draft for that idea, let me know if you see some
problems there:
--- xenbus.c.orig 2018-09-07 12:11:57.798071485 +0200
+++ xenbus.c
>>> On 07.09.18 at 11:57, wrote:
> On 07/09/18 09:48, Jan Beulich wrote:
>> Rather than blindly dropping the logic, I'd have expected
>> for it to be fixed: Despite the movement into XEN_DOMCTL_createdomain
>> there's still a race between ucode updates and domain creation.
>
> What race? What ha
>>> On 23.08.18 at 11:47, wrote:
> @@ -248,12 +252,16 @@ int iommu_construct(struct domain *d)
>
> void iommu_domain_destroy(struct domain *d)
> {
> -if ( !iommu_enabled || !dom_iommu(d)->platform_ops )
> +const struct domain_iommu *hd = dom_iommu(d);
> +
> +if ( !iommu_enabled ||
This requires calling dpkg-deb directly and pass it -z0.
It reduces the time to run the mkdeb script from 14 seconds to 3
seconds on my workstation with SSD, from 87s to 15s on a machine
with HDD. The deb file grows from 49M to 58M.
Signed-off-by: Wei Liu
---
tools/misc/mkdeb | 2 +-
1 file cha
On Fri, Sep 07, 2018 at 12:20:26PM +0200, Valentin Vidic wrote:
> On Fri, Sep 07, 2018 at 09:54:55AM +0200, Roger Pau Monné wrote:
> > Then I'm afraid you will have to look into the vbd_free/create fix.
>
> Yes, here is a first draft for that idea, let me know if you see some
> problems there:
Th
flight 127367 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127367/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4d621893471c6299de06aeac56f4c6cddc5c9ebe
baseline version:
ovmf 7761cee050e706544bfee
>>> On 23.08.18 at 11:47, wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
> obj-y += grant_table.o
> obj-y += guestcopy.o
> obj-bin-y += gunzip.init.o
> +obj-$(CONFIG_X86) += iommu_op.o
Btw - irrespective of this I think
On 07/09/18 11:21, Jan Beulich wrote:
On 07.09.18 at 11:57, wrote:
>> On 07/09/18 09:48, Jan Beulich wrote:
>>> Rather than blindly dropping the logic, I'd have expected
>>> for it to be fixed: Despite the movement into XEN_DOMCTL_createdomain
>>> there's still a race between ucode updates an
>>> On 23.08.18 at 11:47, wrote:
> This patch adds an iommu_op to allow the domain IOMMU reserved ranges to be
> queried by the guest.
>
> NOTE: The number of reserved ranges is determined by system firmware, in
> conjunction with Xen command line options, and is expected to be
> smal
flight 127368 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127368/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 08/24/2018, 04:26 PM, Boris Ostrovsky wrote:
> On 08/24/2018 07:26 AM, Juergen Gross wrote:
>> On 24/08/18 13:12, Jiri Slaby wrote:
>>> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
On 07/29/2018 11:30 PM, David Miller wrote:
> From: Xiao Liang
> Date: Fri, 27 Jul 2018 17:56:08 +0800
>>> On 23.08.18 at 11:47, wrote:
> This patch adds a new method to the VT-d IOMMU implementation to find the
> MFN currently mapped by the specified BFN along with a wrapper function in
> generic IOMMU code to call the implementation if it exists.
For this to go in, I think the AMD side of it wan
On 30/08/18 15:18, Jan Beulich wrote:
On 30.08.18 at 15:06, wrote:
>> This allows all system domids to be printed by name, rather than special
>> casing the idle vcpus alone.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC: Konrad Rzeszutek Wilk
>>
On Fri, 2018-09-07 at 03:48 -0600, Jan Beulich wrote:
> > > > On 03.09.18 at 15:14, wrote:
> >
> > This patch series addresses the ideea of saving data from a single
> > vcpu instance.
> > First it starts by adding *save_one functions, then it introduces a
> > handler for the
> > new save_one* fu
On Fri, Sep 07, 2018 at 12:43:09PM +0200, Roger Pau Monné wrote:
> I would prefer if you could avoid open-coding this here, and instead
> use xen_vbd_create or similar. I would also prefer that the call to
> xen_vbd_create in backend_changed was removed and we had a single call
> to xen_vbd_create
>>> On 23.08.18 at 11:47, wrote:
> The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
> domain's IOMMU pagetable which, prior to this patch, is not strictly true
> since the macro did not test whether the domain actually has IOMMU
> mappings.
Hmm, I would never have implied
On 07/09/18 13:06, Jiri Slaby wrote:
> On 08/24/2018, 04:26 PM, Boris Ostrovsky wrote:
>> On 08/24/2018 07:26 AM, Juergen Gross wrote:
>>> On 24/08/18 13:12, Jiri Slaby wrote:
On 07/30/2018, 10:18 AM, Xiao Liang wrote:
> On 07/29/2018 11:30 PM, David Miller wrote:
>> From: Xiao Liang
>>> On 07.09.18 at 13:15, wrote:
> On Fri, 2018-09-07 at 03:48 -0600, Jan Beulich wrote:
>> > > > On 03.09.18 at 15:14, wrote:
>> >
>> > This patch series addresses the ideea of saving data from a single
>> > vcpu instance.
>> > First it starts by adding *save_one functions, then it introduces a
On Fri, 2018-09-07 at 03:43 -0600, Jan Beulich wrote:
> > > > On 03.09.18 at 15:14, wrote:
> >
> > This patch removes the redundant save functions and renames the
> > save_one* to save. It then changes the domain param to vcpu in the
> > save funcs and adapts print messages in order to match the
On Wed, Sep 05, 2018 at 06:27:56PM +0200, Valentin Vidic wrote:
> On Wed, Sep 05, 2018 at 12:36:49PM +0200, Roger Pau Monné wrote:
> > On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
> > > Switching to closed state earlier can cause the block-drbd
> > > script to fail with 'Device i
On Fri, Sep 07, 2018 at 02:03:37PM +0200, Lars Ellenberg wrote:
> Very frequently it is *NOT* the "original user", that "still" holds it
> open, but udev, or something triggered-by-udev.
>
> So double-checking the udev rules,
> or the "lvm global_filter" settings may help.
> You could instrument D
Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load
module manually") added a new wait queue to wait on for a state change
when the module is loaded manually. Unfortunately there is no wakeup
anywhere to stop that waiting.
Instead of introducing a new wait queue rename the exis
On 09/07/2018 11:59 AM, Andrew Cooper wrote:
> On 07/09/18 11:21, Jan Beulich wrote:
> On 07.09.18 at 11:57, wrote:
>>> On 07/09/18 09:48, Jan Beulich wrote:
Rather than blindly dropping the logic, I'd have expected
for it to be fixed: Despite the movement into XEN_DOMCTL_createdomai
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 September 2018 12:11
> To: Paul Durrant
> Cc: George Dunlap ; Kevin Tian
> ; xen-devel
> Subject: Re: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
>
> >>> On 23.08.18 at 11:47, wrote:
> > This pa
On 07/09/18 13:37, George Dunlap wrote:
> On 09/07/2018 11:59 AM, Andrew Cooper wrote:
>> On 07/09/18 11:21, Jan Beulich wrote:
>> On 07.09.18 at 11:57, wrote:
On 07/09/18 09:48, Jan Beulich wrote:
> Rather than blindly dropping the logic, I'd have expected
> for it to be fixed: D
On 07/09/18 08:41, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> The format identifier is consistent with Linux. The code is adapted from
>> bitmap_scn{,list}printf() but cleaned up.
> Irrespective of this I'm somewhat worried by ...
>
>> --- a/docs/misc/printk-formats.txt
>> +++ b/docs
On 07/09/18 08:51, Jan Beulich wrote:
On 06.09.18 at 17:33, wrote:
>> --- a/include/xen/mem-reservation.h
>> +++ b/include/xen/mem-reservation.h
>> @@ -17,12 +17,17 @@
>>
>> #include
>>
>> +#ifdef CONFIG_XEN_SCRUB_PAGES
>> +extern bool xen_scrub_pages;
>> +
>> static inline void xenmem
On Fri, Sep 07, 2018 at 02:13:48PM +0200, Valentin Vidic wrote:
> On Fri, Sep 07, 2018 at 02:03:37PM +0200, Lars Ellenberg wrote:
> > Very frequently it is *NOT* the "original user", that "still" holds it
> > open, but udev, or something triggered-by-udev.
> >
> > So double-checking the udev rules
On 09/07/2018 02:30 AM, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga946
Am Fri, 7 Sep 2018 09:33:20 -0400
schrieb Boris Ostrovsky :
> what is the purpose of 'xl vcpu-set 0'?
Likely just a script that went wrong. But that command should not break the
dom0.
Olaf
pgpf7yM3gq1fu.pgp
Description: Digitale Signatur von OpenPGP
__
Wei Liu writes ("[PATCH v3 06/16] libxl: don't set PoD target for PV guests"):
> Previously PoD target was unconditionally set for both PV and HVM
> guests, but in fact PoD has always been an HVM (now PVH as well) only
> feature.
Acked-by: Ian Jackson
Wei Liu writes ("[PATCH] mkdeb: use compression level 0"):
> This requires calling dpkg-deb directly and pass it -z0.
>
> It reduces the time to run the mkdeb script from 14 seconds to 3
> seconds on my workstation with SSD, from 87s to 15s on a machine
> with HDD. The deb file grows from 49M to 5
On 09/07/2018 08:21 AM, Juergen Gross wrote:
> Commit 822fb18a82aba ("xen-netfront: wait xenbus state change when load
> module manually") added a new wait queue to wait on for a state change
> when the module is loaded manually. Unfortunately there is no wakeup
> anywhere to stop that waiting.
>
>
On 07/09/18 09:03, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> @@ -2059,11 +2058,10 @@ csched_dump_pcpu(const struct scheduler *ops, int
>> cpu)
>> spc = CSCHED_PCPU(cpu);
>> runq = &spc->runq;
>>
>> -cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask,
On 07/09/18 09:12, Jan Beulich wrote:
On 06.09.18 at 14:08, wrote:
>> --- a/xen/arch/x86/cpu/mcheck/mce.c
>> +++ b/xen/arch/x86/cpu/mcheck/mce.c
>> @@ -535,9 +535,12 @@ void mcheck_cmn_handler(const struct cpu_user_regs
>> *regs)
>> mc_panic("MCE: No CPU found valid MCE, need re
On 05/03/18 09:27, Jan Beulich wrote:
On 27.02.18 at 15:50, wrote:
>> -compat_create_bounce_frame:
>> -ASSERT_INTERRUPTS_ENABLED
>> -mov %fs,%edi
>> -ASM_STAC
>> -testb $2,UREGS_cs+8(%rsp)
>> -jz1f
>> -/* Push new frame at registered guest
On 13/03/18 15:04, Jan Beulich wrote:
On 07.03.18 at 19:58, wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -185,6 +185,10 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr,
>> uint64_t *val)
>> }
>>
>> /* Fallthrough. */
>> +case MSR_XEN_ALT_
The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
BUG: unable to handle kernel NULL pointer dereference at 02d8
PGD 0 P4D 0
Oops: [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-default #1
openSUSE Tumbleweed (unreleased)
Hardw
On 07/09/18 16:31, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted 4.19.0-rc2-1.ga9462db-
On 09/07/2018 02:56 PM, Andrew Cooper wrote:
>> Then again I wonder whether a special
>> case for CPU masks wouldn't be warranted, making it unnecessary for
>> callers to pass in nr_cpu_ids explicitly.
>
> The only way of special casing is to have a different custom %p
> formatter. All printing o
On 09/06/2018 01:08 PM, Andrew Cooper wrote:
> This removes all use of keyhandler_scratch as a bounce-buffer for the rendered
> string. In some cases, collapse combine adjacent printk()'s which are writing
> parts of the same line.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Ack
On 28/06/18 14:56, Jan Beulich wrote:
On 28.06.18 at 15:36, wrote:
>> On 28/06/18 14:00, Jan Beulich wrote:
>> On 26.06.18 at 15:18, wrote:
@@ -49,6 +28,18 @@
#define ARCH_CAPS_RSBA(_AC(1, ULL) << 2)
#define ARCH_CAPS_SSB_NO (_AC(1, ULL) << 4
>>> On 07.09.18 at 14:02, wrote:
> On Fri, 2018-09-07 at 03:43 -0600, Jan Beulich wrote:
>> > > > On 03.09.18 at 15:14, wrote:
>> >
>> > This patch removes the redundant save functions and renames the
>> > save_one* to save. It then changes the domain param to vcpu in the
>> > save funcs and ada
>>> On 07.09.18 at 14:36, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 September 2018 12:11
>> To: Paul Durrant
>> Cc: George Dunlap ; Kevin Tian
>> ; xen-devel
>> Subject: Re: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
>>
>> >
On Fri, Sep 07, 2018 at 08:35:11AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 06 September 2018 19:12
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> > ; George Dunlap
> > ; Ian Jacks
>>> On 07.09.18 at 16:47, wrote:
> On 28/06/18 14:56, Jan Beulich wrote:
> On 28.06.18 at 15:36, wrote:
>>> On 28/06/18 14:00, Jan Beulich wrote:
>>> On 26.06.18 at 15:18, wrote:
> @@ -49,6 +28,18 @@
> #define ARCH_CAPS_RSBA (_AC(1, ULL) << 2)
> #define AR
This is a first patch to implement libxl__ev_qmp, it only connects to
the QMP socket of QEMU and registers a fd callback that does nothing.
Callback functions will be implemented in following patches.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
nits
use a define instead of
Signed-off-by: Anthony PERARD
---
Notes:
v5:
initialize len and s at declaration time
remove old comment
v4:
simplification of the patch due to use of a single allocated space for
the
receive buffer.
tools/libxl/libxl_qmp.c | 52
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_qmp.c | 41 ++---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ffbc055110..90308b1598 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/
To be able to re-use qmp_prepare_qmp_cmd with libxl__ev_qmp.
Also, add the QMP end of command '\r\n' into the generated string.
Signed-off-by: Anthony PERARD
---
Notes:
v5:
rename qmp_prepare_qmp_cmd to qmp_prepare_cmd
fix coding style
tools/libxl/libxl_qmp.c | 56
Changes in v5:
Plenty of patch have been applied.
Other changes mostly are coding style and other typos.
Some bug fixes.
Details can be found in patch notes.
I have left aside the change to cdrom_insert until I can found what to do
with the userdata lock.
Changes in v4:
1 - 100 of 162 matches
Mail list logo
