>>> On 19.12.18 at 18:26, wrote:
> On 12/13/18 10:43 AM, Jan Beulich wrote:
> On 13.12.18 at 11:22, wrote:
>>> For my own part, I see no reason why not clipping end should not work
>>> when updating the ranges only (as long as start continues to be <=
>>> unclipped_end).
>>>
>>> Would that mo
>>> On 20.12.18 at 06:29, wrote:
> On Wed, Dec 12, 2018 at 1:48 AM Jan Beulich wrote:
>>
>> > +static int
>> > +argo_find_ring_mfns(struct domain *d, struct argo_ring_info *ring_info,
>> > +uint32_t npage, XEN_GUEST_HANDLE_PARAM(argo_pfn_t)
>> > pfn_hnd,
>> > +
>>> On 20.12.18 at 06:58, wrote:
> On Wed, Dec 12, 2018 at 3:53 AM Jan Beulich wrote:
>> >>> On 01.12.18 at 02:32, wrote:
>> > +static struct argo_ring_info *
>> > +argo_ring_find_info_by_match(const struct domain *d, uint32_t port,
>> > + domid_t partner_id, uint64_t
>>> On 20.12.18 at 07:12, wrote:
> On Thu, Dec 13, 2018 at 6:06 AM Jan Beulich wrote:
>>
>> >>> On 01.12.18 at 02:32, wrote:
>> > +static uint32_t
>> > +argo_ringbuf_payload_space(struct domain *d, struct argo_ring_info
>> > *ring_info)
>> > +{
>> > +argo_ring_t ring;
>> > +int32_t ret;
flight 131440 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131440/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 204d7bf6cddd87478f9c1a6bb55f482d87cf2eaa
baseline version:
freebsd 3e1a7746aea
>>> On 20.12.18 at 06:16, wrote:
> On Wed, Dec 12, 2018 at 8:03 AM Roger Pau Monné wrote:
>>
>> On Fri, Nov 30, 2018 at 05:32:46PM -0800, Christopher Clark wrote:
>> > Applied to both x86 and ARM headers.
>> >
>> > Signed-off-by: Christopher Clark
>> > ---
>> > xen/include/asm-arm/guest_access.
>>> On 20.12.18 at 06:41, wrote:
> On Wed, Dec 12, 2018 at 8:48 AM Roger Pau Monné wrote:
>>
>> On Fri, Nov 30, 2018 at 05:32:52PM -0800, Christopher Clark wrote:
>> > +static inline uint16_t
>> > +argo_hash_fn(const struct argo_ring_id *id)
>>
>> No need for the argo_ prefix for static functions
>>> On 20.12.18 at 07:38, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -200,6 +200,26 @@ config LATE_HWDOM
>
> If unsure, say N.
>
> +config ARGO
> + def_bool n
> + prompt "Argo: hypervisor-mediated interdomain communication" if EXPERT
> = "y"
The common
On Wed, Dec 19, 2018 at 06:10:04PM +, George Dunlap wrote:
> On 12/19/18 2:59 PM, Roger Pau Monné wrote:
> >> Using 'current' means that potential deadlocks which would now cause a
> >> BUG() won't anymore. I'm fine with not adding extra protections that
> >> aren't there now; but I don't want
>>> On 19.12.18 at 17:49, wrote:
> On 27.11.2018 13:32, Roger Pau Monné wrote:
>> Would it be possible to add some kind of flag to the emulator to
>> signal whether p2m restrictions should be enforced/ignored?
>> hvmemul_acquire_page seems like a suitable place, but I'm not that
>> familiar with t
>>> On 20.12.18 at 10:05, wrote:
> On Wed, Dec 19, 2018 at 06:10:04PM +, George Dunlap wrote:
>> On 12/19/18 2:59 PM, Roger Pau Monné wrote:
>> >> Using 'current' means that potential deadlocks which would now cause a
>> >> BUG() won't anymore. I'm fine with not adding extra protections that
On Thu, Dec 20, 2018 at 10:46:29AM +0800, Chao Gao wrote:
> On Wed, Dec 19, 2018 at 09:57:51AM +0100, Roger Pau Monné wrote:
> >On Tue, Dec 18, 2018 at 10:43:37PM +0800, Chao Gao wrote:
> >> I find some pass-thru devices don't work any more across guest
> >> reboot. Assigning it to another domain a
On Thu, Dec 20, 2018 at 02:16:15AM -0700, Jan Beulich wrote:
> >>> On 20.12.18 at 10:05, wrote:
> > On Wed, Dec 19, 2018 at 06:10:04PM +, George Dunlap wrote:
> >> On 12/19/18 2:59 PM, Roger Pau Monné wrote:
> >> >> Using 'current' means that potential deadlocks which would now cause a
> >> >>
>>> On 20.12.18 at 10:58, wrote:
> On Thu, Dec 20, 2018 at 02:16:15AM -0700, Jan Beulich wrote:
>> >>> On 20.12.18 at 10:05, wrote:
>> > On Wed, Dec 19, 2018 at 06:10:04PM +, George Dunlap wrote:
>> >> On 12/19/18 2:59 PM, Roger Pau Monné wrote:
>> >> >> Using 'current' means that potential d
On Wed, 2018-12-19 at 15:33 -0700, Tamas K Lengyel wrote:
> On Wed, Dec 19, 2018 at 11:52 AM 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 l
On 12/19/18 4:10 PM, Gerd Hoffmann wrote:
Hi,
Sure this actually helps? It's below 4G in guest physical address
space, so it can be backed by pages which are actually above 4G in host
physical address space ...
Yes, you are right here. This is why I wrote about the IOMMU
and other conditio
Hi Christopher,
On 12/20/18 6:39 AM, Christopher Clark wrote:
Used by a domain to register a region of memory for receiving messages from
either a specified other domain, or, if specifying a wildcard, any domain.
This operation creates a mapping within Xen's private address space that
will rema
On 15.11.18 17:22, Julien Grall wrote:
The reason I didn't move the other one in p2m.c is because so far p2m.c is only
dealing with auto-translated guest. I didn't want to add function related with
non-auto translated guest in it.
I also don't think introduce a new file for one 10 line funct
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 12/19/18 6:14 PM, Noralf Trønnes wrote:
Den 19.12.2018 09.18, skrev Oleksandr Andrushchenko:
On 12/18/18 9:20 PM, Noralf Trønnes wrote:
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the bac
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Petre Pircalabu
> Sent: 19 December 2018 18:52
> To: xen-devel@lists.xenproject.org
> Cc: Petre Pircalabu ; Stefano Stabellini
> ; Wei Liu ; Razvan Cojocaru
> ; Konrad Rzeszutek Wilk
> ; Ge
On Wed, 2018-12-19 at 15:26 -0700, Tamas K Lengyel wrote:
> On Wed, Dec 19, 2018 at 11:52 AM Petre Pircalabu
> wrote:
> >
> > Decouple the VM Event interface from the ring implementation.
>
> This will need a much better description. There is also a lot of
> churn
> that is mostly just mechanica
On Wed, Dec 19, 2018 at 09:41:59PM -0800, Christopher Clark wrote:
> On Wed, Dec 12, 2018 at 8:48 AM Roger Pau Monné wrote:
> >
> > On Fri, Nov 30, 2018 at 05:32:52PM -0800, Christopher Clark wrote:
> > > +static inline uint16_t
> > > +argo_hash_fn(const struct argo_ring_id *id)
> >
> > No need fo
On Wed, Dec 19, 2018 at 09:16:38PM -0800, Christopher Clark wrote:
> On Wed, Dec 12, 2018 at 8:03 AM Roger Pau Monné wrote:
> >
> > On Fri, Nov 30, 2018 at 05:32:46PM -0800, Christopher Clark wrote:
> > > Applied to both x86 and ARM headers.
> > >
> > > Signed-off-by: Christopher Clark
> > > ---
On 30.11.18 18:59, David Hildenbrand wrote:
> This is the second approach, introducing more meaningful memory block
> types and not changing online behavior in the kernel. It is based on
> latest linux-next.
>
> As we found out during dicussion, user space should always handle onlining
> of memory
On 12/20/18 8:20 AM, Jan Beulich wrote:
On 19.12.18 at 18:26, wrote:
>> On 12/13/18 10:43 AM, Jan Beulich wrote:
>> On 13.12.18 at 11:22, wrote:
For my own part, I see no reason why not clipping end should not work
when updating the ranges only (as long as start continues to be
On Thu 20-12-18 13:58:16, David Hildenbrand wrote:
> On 30.11.18 18:59, David Hildenbrand wrote:
> > This is the second approach, introducing more meaningful memory block
> > types and not changing online behavior in the kernel. It is based on
> > latest linux-next.
> >
> > As we found out during
The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.
Signed-off-by: Pu Wen
---
xen/arch/x86/cpu/common.c | 3 ++-
xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 5 +++--
xen
Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. Carve out initialization codes from amd.c needed by Dhyana into a
separate file hygon.c by removing unnecessary codes and make Hygon
initialization codes more clear.
To identify Hygon Dhyana CPU, add a new vendor type X86_V
The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.
Signed-off-by: Pu Wen
---
xen/arch/x86/cpu/mtrr/generic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86
The PMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. To support it, add Hygon Dhyana support in the similar
way as AMD does.
Signed-off-by: Pu Wen
---
xen/arch/x86/cpu/vpmu.c | 2 ++
xen/arch/x86/cpu/vpmu_amd.c | 2 ++
2 files changed, 4 insertions(+)
diff --g
As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a Joint Venture between AMD and Haiguang Information Technology Co.,
Ltd., and aims at providing high performance x86 processor for China
server market.
The first generation Hygon's processor(Dhyana) originates from AMD
techno
Add Hygon Dhyana support to use modern APIC.
Signed-off-by: Pu Wen
---
xen/arch/x86/apic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 2a24326..004d685 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -92,6 +92,11 @@ stati
Add Hygon Dhyana support to the acpi cpufreq subsystem by using the code
path of AMD.
Signed-off-by: Pu Wen
---
xen/arch/x86/acpi/cpu_idle.c | 3 ++-
xen/arch/x86/acpi/cpufreq/cpufreq.c | 6 --
xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++-
3 files changed, 8 insertions(+), 4 deletio
The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.
Signed-off-by: Pu Wen
---
xen/arch/x86/spec_ctrl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/spec_ctrl.c b/xen
The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support to it by sharing the code
path of AMD.
Signed-off-by: Pu Wen
---
xen/include/asm-x86/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/asm-x86/iommu.h b/xen/inc
The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR_01DD. So add support for it if the boot param
ler is true.
Signed-off-by: Pu Wen
---
xen/arch/x86/traps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
Add Hygon Dhyana support to update cpuid info for creating PV guest.
Signed-off-by: Pu Wen
---
xen/arch/x86/domctl.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index aa8ad19..a64c724 100644
--- a/xen/arch/x86/d
Add Hygon Dhyana support to handle HyperTransport range.
Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.
Signed-off-by: Pu Wen
---
xen/arch/x86/dom0_build.c | 3 ++-
xen/arch/x86/domain.c | 9 +
The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.
As hygon.c needs
The Hygon Dhyana CPU don't save/restore FDP/FIP/FOP unless an exception
is pending. So add support for it in the function xrstor.
Signed-off-by: Pu Wen
---
xen/arch/x86/xstate.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
The Hygon Dhyana family 18h processor shares the same cpuid leaves as the
AMD family 17h one. So add Hygon Dhyana support to caculate the cpuid
policies as the AMD CPU does.
Signed-off-by: Pu Wen
---
xen/arch/x86/cpuid.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --gi
Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.
Signed-off-by: Pu Wen
---
tools/libxc/xc_cpuid_x86.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/
On 20.12.18 14:08, Michal Hocko wrote:
> On Thu 20-12-18 13:58:16, David Hildenbrand wrote:
>> On 30.11.18 18:59, David Hildenbrand wrote:
>>> This is the second approach, introducing more meaningful memory block
>>> types and not changing online behavior in the kernel. It is based on
>>> latest li
flight 131439 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131439/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
131416
test-amd64-amd64
On 12/20/18 9:05 AM, Roger Pau Monné wrote:
> On Wed, Dec 19, 2018 at 06:10:04PM +, George Dunlap wrote:
>> On 12/19/18 2:59 PM, Roger Pau Monné wrote:
Using 'current' means that potential deadlocks which would now cause a
BUG() won't anymore. I'm fine with not adding extra protectio
>>> On 20.12.18 at 13:59, wrote:
> On 12/20/18 8:20 AM, Jan Beulich wrote:
> On 19.12.18 at 18:26, wrote:
>>> On 12/13/18 10:43 AM, Jan Beulich wrote:
>>> On 13.12.18 at 11:22, wrote:
> For my own part, I see no reason why not clipping end should not work
> when updating the rang
+ARM mailing list for help and suggestions
Dear ARM community!
Xen hypervizor para-virtualized DRM frontend driver [1] uses shmem
backed pages for display buffers and shares those with the host
driver. Everything works just fine, but in some scenarios I see
artifacts on the screen which are beca
>>> On 20.12.18 at 14:47, wrote:
> On 12/20/18 9:05 AM, Roger Pau Monné wrote:
>> On Wed, Dec 19, 2018 at 06:10:04PM +, George Dunlap wrote:
>>> On 12/19/18 2:59 PM, Roger Pau Monné wrote:
> Using 'current' means that potential deadlocks which would now cause a
> BUG() won't anymore.
On Thu, Dec 20, 2018 at 3:48 AM Petre Ovidiu PIRCALABU
wrote:
>
> On Wed, 2018-12-19 at 15:33 -0700, Tamas K Lengyel wrote:
> > On Wed, Dec 19, 2018 at 11:52 AM Petre Pircalabu
> > wrote:
> > >
> > > This patchset is a rework of the "multi-page ring buffer" for
> > > vm_events
> > > patch based o
On Thu, Dec 20, 2018 at 10:29:14AM +0100, Roger Pau Monné wrote:
>On Thu, Dec 20, 2018 at 10:46:29AM +0800, Chao Gao wrote:
>> On Wed, Dec 19, 2018 at 09:57:51AM +0100, Roger Pau Monné wrote:
>> >On Tue, Dec 18, 2018 at 10:43:37PM +0800, Chao Gao wrote:
>> >> I find some pass-thru devices don't wor
On 12/20/18 2:01 PM, Jan Beulich wrote:
>> The practical implication of dom0 bias is that any hypercall which grabs
>> two mm locks, one of two things must be true:
>> * When it is called from one domU to another domU, locks must follow the
>> "normal" locking order listed in mm-locks.h
>
> This w
On Thu, 2018-12-20 at 12:05 +, Paul Durrant wrote:
> > The memory for the asynchronous ring and the synchronous channels
> > will
> > be allocated from domheap and mapped to the controlling domain
> > using the
> > foreignmemory_map_resource interface. Unlike the current
> > implementation,
> >
On 12/20/18 8:12 AM, Pu Wen wrote:
> The PMU architecture for the Hygon Dhyana CPU is similar to the AMD
> family 17h one. To support it, add Hygon Dhyana support in the similar
> way as AMD does.
>
> Signed-off-by: Pu Wen
> ---
> xen/arch/x86/cpu/vpmu.c | 2 ++
> xen/arch/x86/cpu/vpmu_amd.c
> -Original Message-
> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
> Sent: 20 December 2018 14:26
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; Razvan Cojocaru ; Konrad
> Rzeszutek Wilk ; George Dunlap
> ; Andrew Cooper ; Ian
On 19.12.2018 19:40, Roger Pau Monné wrote:
> On Wed, Dec 19, 2018 at 04:49:43PM +, Alexandru Stefan ISAILA wrote:
>> On 27.11.2018 13:32, Roger Pau Monné wrote:
>>> Would it be possible to add some kind of flag to the emulator to
>>> signal whether p2m restrictions should be enforced/ignored
On 12/20/18 1:52 PM, Jan Beulich wrote:
On 20.12.18 at 13:59, wrote:
>> On 12/20/18 8:20 AM, Jan Beulich wrote:
>> On 19.12.18 at 18:26, wrote:
On 12/13/18 10:43 AM, Jan Beulich wrote:
On 13.12.18 at 11:22, wrote:
>> For my own part, I see no reason why not clipping en
On 20/12/2018, 06:39, "Christopher Clark"
wrote:
The software license on the public header is the BSD license, standard
procedure for the public Xen headers.
Thank you for posting the patch. I think it is important to note that these
headers were originally posted under a GPL li
Jan Beulich writes ("[PATCH] x86emul: fix test harness and fuzzer build
dependencies"):
> --- a/tools/fuzz/x86_instruction_emulator/Makefile
> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
...
> +$(XEN_ROOT)/tools/include/xen/lib/x86/cpuid-autogen.h: FORCE
> + $(MAKE) -C $(XEN_ROOT)/tools
>>> On 20.12.18 at 15:38, wrote:
> Can we just for now take the text as I proposed it? You can argue about
> the right thing to do when we do the alleged clean-up.
With the "We should probably return an error ..." part dropped
or replaced by e.g. "We should revisit this" this would be okay
with
>>> On 20.12.18 at 15:46, wrote:
> Jan Beulich writes ("[PATCH] x86emul: fix test harness and fuzzer build
> dependencies"):
>> --- a/tools/fuzz/x86_instruction_emulator/Makefile
>> +++ b/tools/fuzz/x86_instruction_emulator/Makefile
> ...
>> +$(XEN_ROOT)/tools/include/xen/lib/x86/cpuid-autogen.h:
>>> On 20.12.18 at 15:38, wrote:
> At the moment I'm only working 4-ish more days between now and the code
> freeze, and we're arguing over whether the comment should say, "We
> should probably do X instead" or "We should probably do Y instead."
>
> Can we just for now take the text as I proposed
>>> On 20.12.18 at 15:28, wrote:
>> -Original Message-
>> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
>> Sent: 20 December 2018 14:26
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Wei Liu
>> ; Razvan Cojocaru ; Konrad
>> Rzeszutek W
On 12/20/18 4:49 PM, Jan Beulich wrote:
On 20.12.18 at 15:38, wrote:
>> Can we just for now take the text as I proposed it? You can argue about
>> the right thing to do when we do the alleged clean-up.
>
> With the "We should probably return an error ..." part dropped
> or replaced by e.g.
>>> On 20.12.18 at 07:38, wrote:
> Presence is gated upon CONFIG_ARGO.
>
> Registers the hypercall previously reserved for this.
> Takes 5 arguments, does nothing and returns -ENOSYS.
>
> Will be avoiding a compat ABI by using fixed-size types in hypercall ops so
> HYPERCALL, rather than COMPAT_
>>> On 20.12.18 at 07:39, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -19,6 +19,19 @@
> #include
> #include
>
> +/*
> + * Debug
> + */
> +
> +/* Set ARGO_DEBUG to 1 here to enable more debug messages */
> +#define ARGO_DEBUG 0
> +
> +#ifdef ARGO_DEBUG
Well, either the wa
>>> On 20.12.18 at 07:39, wrote:
> EMSGSIZE: Argo's sendv operation will return EMSGSIZE when an excess amount
> of data, across all iovs, has been supplied, exceeding either the statically
> configured maximum size of a transmittable message, or the (variable) size
> of the ring registered by the
Also clean up current code by moving initialization of arch specific
fields out of common code.
Signed-off-by: Chao Gao
---
Changes in v4:
- newly added
---
xen/drivers/passthrough/pci.c | 2 +-
xen/include/asm-x86/msi.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git
When I destroyed a guest with 'xl destroy', I found the warning
in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
to that place, I got the call trace below:
(XEN) Xen call trace:
(XEN)[] msi.c#msi_set_mask_bit+0x1da/0x29b
(XEN)[] guest_mask_msi_irq+0x1c/0x1e
(XEN)[]
On 12/20/18 3:14 PM, Razvan Cojocaru wrote:
> On 12/20/18 4:49 PM, Jan Beulich wrote:
> On 20.12.18 at 15:38, wrote:
>>> Can we just for now take the text as I proposed it? You can argue about
>>> the right thing to do when we do the alleged clean-up.
>>
>> With the "We should probably return
I find some pass-thru devices don't work any more across guest
reboot. Assigning it to another domain also meets the same issue. And
the only way to make it work again is un-binding and binding it to
pciback. Someone reported this issue one year ago [1].
If the device's driver doesn't disable MSI-
Jan Beulich writes ("Re: [PATCH] x86emul: fix test harness and fuzzer build
dependencies"):
> On 20.12.18 at 15:46, wrote:
> > I think this introduces a `make -j' hazard ? The problem is that this
> > branch of the Makefiles tree might enter tools/include while
> > another branch is also doing s
>>> On 20.12.18 at 07:39, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -35,6 +35,22 @@ DEFINE_XEN_GUEST_HANDLE(xen_argo_ring_t);
> static bool __read_mostly opt_argo_enabled;
> boolean_param("argo", opt_argo_enabled);
>
> +/* Xen command line option for conservative or relax
On Tue, Dec 18, 2018 at 08:20:22PM +0100, Noralf Trønnes wrote:
> > + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> > + DMA_BIDIRECTIONAL)) {
>
>
> Are you using the DMA streaming API as a way to flush the caches?
This looks rather broken. Please send t
On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
> 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 intentional
On Wed, Dec 19, 2018 at 02:14:52PM +0100, Gerd Hoffmann wrote:
>
> > > > + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> > > > + DMA_BIDIRECTIONAL)) {
> > >
> > >
> > > Are you using the DMA streaming API as a way to flush the caches?
> > Yes
> > > Does this m
On 12/20/18 5:36 PM, Christoph Hellwig wrote:
On Tue, Dec 18, 2018 at 08:20:22PM +0100, Noralf Trønnes wrote:
+ if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
+ DMA_BIDIRECTIONAL)) {
Are you using the DMA streaming API as a way to flush the caches
>>> On 20.12.18 at 16:23, wrote:
> Jan Beulich writes ("Re: [PATCH] x86emul: fix test harness and fuzzer build
> dependencies"):
>> On 20.12.18 at 15:46, wrote:
>> > I think this introduces a `make -j' hazard ? The problem is that this
>> > branch of the Makefiles tree might enter tools/include
On 12/19/18 4:25 PM, Ken Pizzini wrote:
> Since 4.19.5 I have not been able to boot kernels on my Xen-hosted VM on
> a system with an Intel Xeon L5520 processor (microcode 0x1d).
>
> 4.19.4 worked fine; I've tried kernels 4.19.5, 4.19.6, 4.19.7 4.19.9, 4.19.10,
> 4.20-rc7, and they all throw:
>
On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
> 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:
>
> - Documen
On 12/20/18 6:09 PM, George Dunlap wrote:
> On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
>> 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
On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
> change_type_range() 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
On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
> 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:
>
> - Documen
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch als
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This p
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept m
On 12/20/18 6:31 PM, George Dunlap wrote:
> On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
>> 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
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; they will be added to by subsequent patches.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/arch/x86/hvm/hvm.c |
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
Signed-off-by: Paul Dur
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by:
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the infrastructure
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
NOTE: It is necessary for correct operation that timer expiration and
This is currently a fairly large feature gap between Xen and KVM.
Paul Durrant (8):
viridian: add init hooks
viridian: separately allocate domain and vcpu structures
viridian: extend init/deinit hooks into synic and time modules
viridian: add missing context save helpers into synic and tim
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 xen_
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'
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
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabell
...and xen_backend.h to xen-legacy-backend.h
Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends. Hence it is necessary to r
The new xen-block 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-block.c source module as the basis for the new dataplane and
adjusts
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
th
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
1 - 100 of 164 matches
Mail list logo
