For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
doesn't support INTx mode, so its machine irq read from host sysfs is 0.
In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
continue.
Cc: Roger Pau Monné
Cc: Jan Beulich
Signed-off-by: Zhao Yan
---
v2:
On Mon, Dec 03, 2018 at 12:20:30PM +0100, Roger Pau Monné wrote:
> Hello,
>
> Thanks for the patch.
>
> The subject should be more descriptive, "Fix a xen passthrough
> failure" is too generic. How about: "allow passthrough of devices with
> bogus interrupt pin" or something similar.
right,
Hi all,
When I make grub, I met error " too few arguments to function
'grub_create_loader_cmdline'" with xen.
I used git bisect and found the error occurred from commit:
4d4a8c96e3593d76fe7b025665ccdecc70a53c1f.
Do you have any ideas? Thanks a lot!
commit
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The
flight 130906 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130906/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
On 12/3/2018 6:16 PM, Boris Ostrovsky wrote:
On 12/3/18 8:14 PM, Dongli Zhang wrote:
Hi Boris,
On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
On 12/2/18 3:31 PM, Manjunath Patil wrote:
On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
On 11/30/18 4:49 PM, Manjunath Patil wrote:
Thank you
Missing the DT list...
On Mon, Dec 3, 2018 at 3:43 PM Stefano Stabellini
wrote:
>
> From: Stefano Stabellini
>
> Introduce a device tree binding for Xen reserved-memory regions. They
> are used to share memory across VMs from the VM config files. (See
> static_shm config option.)
>
>
On 04/12/2018 02:14, Dongli Zhang wrote:
> Hi Boris,
>
> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
>> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>>
On 11/30/18 4:49 PM, Manjunath Patil wrote:
> Thank you Boris for your comments. I
On Mon, Dec 3, 2018 at 11:52 AM Mike Rapoport wrote:
>
> On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> > Hi Mike,
> >
> > On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> > >
> > > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > > Previouly
Hi Julien,
Awesome, after applying those patches in latest xen, hikey960 able to
enable 4 CPUs and other four CPUs are giving error -5.
And after using "hmp-unsafe" in xen command line, all CPUs got enabled
successfully.
Thank you,
Omkar B
On Mon, Dec 3, 2018 at 7:27 PM Julien Grall wrote:
>
‐‐‐ Original Message ‐‐‐
On Monday, December 3, 2018 1:07 PM, Rian Quinn wrote:
>> Xen signals in the FADT that there's no VGA, but I won't be surprised
>> that some OSes simply ignore this bit because there are systems with
>> broken ACPI tables out there with the bit set and VGA.
>
>
On 12/3/18 8:14 PM, Dongli Zhang wrote:
> Hi Boris,
>
> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
>> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>>
On 11/30/18 4:49 PM, Manjunath Patil wrote:
> Thank you Boris for your comments. I
On Wed, Nov 28, 2018 at 2:57 PM Razvan Cojocaru
wrote:
>
> 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 allocates a new logdirty rangeset for each new altp2m,
> and
Hi Boris,
On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>
>>> On 11/30/18 4:49 PM, Manjunath Patil wrote:
Thank you Boris for your comments. I removed faulty email of mine.
replies
Hi Manjunath,
On 12/04/2018 10:49 AM, Manjunath Patil wrote:
> On 12/3/2018 6:16 PM, Boris Ostrovsky wrote:
>
>> On 12/3/18 8:14 PM, Dongli Zhang wrote:
>>> Hi Boris,
>>>
>>> On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
On 12/2/18 3:31 PM, Manjunath Patil wrote:
> On 11/30/2018 2:33
Hello,
I'm currently attempting to add guard pages to a Xen-based unikernel. These
are memory regions that cannot be read, written, or executed, could be
potentially ones up to 1MB in size, and would, for instance, separate the
stack and the heap to prevent buffer overflows and stack clashes.
hi Andrew,
It's a pci device that does not support legacy intx mode, but it accidently
reports PCI_INTERRUPT_PIN as 1, which should be 0 instead.
So, in dom0, the machine irq is 0, which will cause later
xc_physdev_map_pirq() fail and passthrough failure.
Therefore, we treat this case as
>>> On 30.11.18 at 18:07, wrote:
> Also, I'm not entirely convinced that making modrm an annonymous union is
> going to work with older CentOS compilers,
It certainly won't.
> and therefore am not sure whether
> that part of the change is worth it. The instruction in question can be
> obtained
On Sat, Dec 01, 2018 at 09:21:00AM -0700, Rian Quinn wrote:
> We finally have a Linux PVH guest up and running (using an initramfs right
> now). I have posted a quick status update video on YouTube that shows our
> progress of getting a Windows Dom0 working (which is one of the many goals
> of our
On 03/12/2018 10:32, Jan Beulich wrote:
On 30.11.18 at 18:07, wrote:
>> Also, I'm not entirely convinced that making modrm an annonymous union is
>> going to work with older CentOS compilers,
> It certainly won't.
>
>> and therefore am not sure whether
>> that part of the change is worth it.
Hello Julien,
On 27.11.18 17:13, Julien Grall wrote:
Oversubscribing is usually a pretty bad idea if you want to have good
latency. There are no promise when the vCPU will get scheduled.
Yes, I know and clearly understand that. But we still have requirements.
So can you describe how
On Thu, Nov 08, 2018 at 07:29:17PM +0200, Pasi Kärkkäinen wrote:
> Hello Ian,
>
> On Tue, Oct 09, 2018 at 03:04:52AM -0600, Jan Beulich wrote:
> > >>> On 09.10.18 at 10:38, wrote:
> > > On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
> > >> All,
> > >>
> > >> both releases are due
On Sun, Dec 02, 2018 at 06:47:33PM +0100, Marek Marczykowski-Górecki wrote:
> From: Dwayne Litzenberger
>
> Newer AMD GPUs store their initialization routines as bytecode on the
> ROM. This fixes the following initialization error inside the VM when
> doing PCI passthrough:
>
> radeon
On 11/26/18 2:15 PM, Oleksandr Andrushchenko wrote:
Hello, all!
My driver (Xen para-virtualized frontend) in some scenarios uses
drm_gem_get_pages for allocating backing storage for dumb buffers.
There are use-cases which showed some artifacts on the screen
(modetest, other) which were worked
Ping? Can I get an ack or otherwise from an AMD maintainer please?
Paul
> -Original Message-
> From: Andrew Cooper
> Sent: 28 November 2018 10:41
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Brian Woods ; Suravee Suthikulpanit
>
> Subject: Re: [Xen-devel] [PATCH v3]
If our run of pandoc to convert pieces of markup in our hand, into
html, fails, print the json that was rejected.
No change in non-error cases.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git
Signed-off-by: Ian Jackson
---
SUPPORT.md | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 42577d0243..291e149503 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -13,7 +13,9 @@ for the definitions of the support status levels etc.
Now, as well as a `code block', with
|Something: some status
we tolerate a definition list which in pandoc terms looks like this
|Term
|: Definition
This ought not usually be be used for features but it will be useful
for linking to the release notes, because markup is not allowed in
An example of the results of this can be seen here:
http://xenbits.xenproject.org/people/iwj/2018/support-matrix-example-4/t.html
http://xenbits.xenproject.org/people/iwj/2018/support-matrix-example-4/SUPPORT.html#release-support
The only part of this that needs to be backported is the part
We are going to want to reuse this. No functional change.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index bbe4d045e1..e2d0187dd1 100755
---
In fact this was not markdown content, but just a string. We are
however going to make it be markdown content. So adjust the comments,
and the consumer.
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 66725236f2..bbe4d045e1 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -118,8 +118,8 @@ sub ri_Header
Signed-off-by: Ian Jackson
---
docs/parse-support-md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/parse-support-md b/docs/parse-support-md
index 99ce547c11..66725236f2 100755
--- a/docs/parse-support-md
+++ b/docs/parse-support-md
@@ -5,10 +5,10 @@
#
# usage:
#
>>> On 01.12.18 at 13:43, wrote:
> flight 130858 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/130858/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64 6 xen-build
>>> On 30.11.18 at 19:01, wrote:
> On Fri, Nov 30, 2018 at 05:09:42PM +, Ian Jackson wrote:
>> Wei Liu writes ("[PATCH v2 0/3] Remove tmem"):
>> > It is agreed that tmem can be removed from xen.git. See the thread
>> > starting
>
>>> On 03.12.18 at 10:10, wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 30 November 2018 17:07
>>
>> RFC: __get_instruction_length_from_list() tries to cope with VMEXIT_IOIO,
>> but
>> IN/OUT instructions aren't in the decode list and I can't spot an entry
>> point
>>
On 03/12/2018 11:13, Borislav Petkov wrote:
> On Sun, Dec 02, 2018 at 08:23:05PM +, Andrew Cooper wrote:
>> Hello,
>>
>> I have dual socket server with the following processor:
>>
>> [root@xrtmia-09-01 ~]# head /proc/cpuinfo
>> processor: 0
>> vendor_id: AuthenticAMD
>> cpu family :
> -Original Message-
> From: Andrew Cooper
> Sent: 03 December 2018 11:14
> To: Paul Durrant ; Xen-devel de...@lists.xen.org>
> Cc: Jan Beulich ; Wei Liu ; Roger
> Pau Monne ; Jun Nakajima ;
> Kevin Tian ; Boris Ostrovsky
> ; Suravee Suthikulpanit
> ; Brian Woods ;
> Juergen Gross
>
On Mon, Dec 03, 2018 at 02:49:34AM -0700, Jan Beulich wrote:
> >>> On 01.12.18 at 13:43, wrote:
> > flight 130858 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/130858/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including
Hi Andrii,
On 03/12/2018 12:33, Andrii Anisov wrote:
On 29.11.18 14:14, Andre Przywara wrote:
Nah, please don't do this.
Sorry for making you crying looking at this code.
It's terrible, I know. It's rather an idea.
Can you show that atomic bit ops are a
problem? They shouldn't be expensive
On 12/3/18 11:36 AM, Takashi Iwai wrote:
On Fri, 30 Nov 2018 08:42:05 +0100,
Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Signed-off-by: Oleksandr Andrushchenko
For
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 December 2018 10:21
> To: Andrew Cooper ; Paul Durrant
>
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Roger Pau Monne ; Wei Liu ;
> Kevin Tian ; Stefano Stabellini
> ; xen-devel
> Subject:
On 03/12/2018 13:16, Ian Jackson wrote:
> An example of the results of this can be seen here:
>
> http://xenbits.xenproject.org/people/iwj/2018/support-matrix-example-4/t.html
>
> http://xenbits.xenproject.org/people/iwj/2018/support-matrix-example-4/SUPPORT.html#release-support
>
> The
On 03/12/2018 09:17, Paul Durrant wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index 365eeb2..a9f9b9b 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3589,6 +3589,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>
flight 130893 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130893/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 129676
Tests which
On Sun, Dec 02, 2018 at 08:23:05PM +, Andrew Cooper wrote:
> Hello,
>
> I have dual socket server with the following processor:
>
> [root@xrtmia-09-01 ~]# head /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family: 23
> model : 1
> model name: AMD
On Sun, Dec 02, 2018 at 06:47:32PM +0100, Marek Marczykowski-Górecki wrote:
> From: Dwayne Litzenberger
I think this requires some description. At least a note that the
function is not altered, just errors from pci reads/writes are no
longer ignored.
> Signed-off-by: Dwayne Litzenberger
> ---
On Mon, Dec 03, 2018 at 05:28:08AM -0700, Jan Beulich wrote:
> >>> On 03.12.18 at 12:57, wrote:
> > On Mon, Dec 03, 2018 at 02:49:34AM -0700, Jan Beulich wrote:
> >> >>> On 01.12.18 at 13:43, wrote:
> >> > flight 130858 xen-unstable real [real]
> >> >
flight 75632 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/75632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-i386-sid-netboot-pvgrub 10 debian-di-install fail like 75621
On 03.12.18 14:17, Julien Grall wrote:
No. I meant that I would be happy with that and I think should also suit
you.
Great!
There are no isb() in do_trap_irq(). So did you mean gic_interrupt()?
Right you are.
But then, I am not sure why you want to avoid the isb() in the guest path.
Well,
On 03/12/2018 13:05, Andrii Anisov wrote:
Hello Julien,
On 03.12.18 14:58, Julien Grall wrote:
That's micro optimizing Xen... there are better (and less risky) place to look
for optimization.
I would appreciate you point me those places.
I already pointed them in various threads with you.
Hi Andrii,
On 03/12/2018 12:58, Andrii Anisov wrote:
On 03.12.18 14:17, Julien Grall wrote:
No. I meant that I would be happy with that and I think should also suit you.
Great!
There are no isb() in do_trap_irq(). So did you mean gic_interrupt()?
Right you are.
But then, I am not sure
On Fri, 30 Nov 2018 08:42:05 +0100,
Oleksandr Andrushchenko wrote:
>
> From: Oleksandr Andrushchenko
>
> Use page directory based shared buffer implementation
> now available as common code for Xen frontend drivers.
>
> Signed-off-by: Oleksandr Andrushchenko
For the sound bits,
>>> On 30.11.18 at 18:07, wrote:
> For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
> supports the instruction, but the guest may have not have rdtscp in its
> featureset. Bring the vmexit handlers in line with the main emulator
> behaviour by optionally handing back #UD.
This run is configured for baseline tests only.
flight 75631 xen-4.8-testing real [real]
http://osstest.xensource.com/osstest/logs/75631/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win10-i386 10
On 01/12/2018 17:21, Rian Quinn wrote:
> We finally have a Linux PVH guest up and running (using an
> initramfs right now). I have posted a quick status update video on
> YouTube that shows our progress of getting a Windows Dom0 working (which
> is one of the many goals of our research).
>
Hello,
Thanks, this is very interesting.
On Sat, Dec 01, 2018 at 09:21:00AM -0700, Rian Quinn wrote:
> We finally have a Linux PVH guest up and running (using an initramfs right
> now). I have posted a quick status update video on YouTube that shows our
> progress of getting a Windows Dom0
Hi Andrii,
On 03/12/2018 12:08, Andrii Anisov wrote:
On 27.11.18 17:13, Julien Grall wrote:
The steps for Xen IRQ is roughly:
-> read_irq
-> local_irq_enable
-> do_IRQ
-> local_irq_enable (via spin_unlock_irq)
-> call handlers
-> local_irq_disable (via
flight 130894 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130894/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 129914
test-armhf-armhf-libvirt-raw 13
>>> On 02.12.18 at 18:47, wrote:
> From: Dwayne Litzenberger
>
> Signed-off-by: Dwayne Litzenberger
At least in the kernel world I think your own SOB is expected here.
Also the description would better be non-empty, explaining under
what conditions failure was observed (and wrongly ignored),
On Fri, Nov 23, 2018 at 11:57:10AM +, Ben Clewett wrote:
> Hi Guys,
>
> I am interested in using Inter-VM-Communications (IVMC) to enhance performance
> between TCP server/applications running on the same Hypervisor.
If it is socket API that you want, maybe pvcalls fits your need?
Hello,
Thanks for the patch.
The subject should be more descriptive, "Fix a xen passthrough
failure" is too generic. How about: "allow passthrough of devices with
bogus interrupt pin" or something similar.
On Mon, Dec 03, 2018 at 12:04:38AM -0500, Zhao Yan wrote:
> For some pci device, even its
On 03/12/2018 12:15, Xin Li (Talons) wrote:
> Hi Juergen,
> thanks for your comments.
>
>Are you suggesting to call apic_is_x2apic_enabled() in __x2apic_disable()?
>but I think that's exact what changed due to the fake xen_cpuid value.
>Doing so will probably still see the EXTD
>>> On 03.12.18 at 12:57, wrote:
> On Mon, Dec 03, 2018 at 02:49:34AM -0700, Jan Beulich wrote:
>> >>> On 01.12.18 at 13:43, wrote:
>> > flight 130858 xen-unstable real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/130858/
>> >
>> > Regressions :-(
>> >
>> > Tests which did not
Hello Julien,
On 03.12.18 14:58, Julien Grall wrote:
That's micro optimizing Xen... there are better (and less risky) place
to look for optimization.
I would appreciate you point me those places.
Knowing how fragile the locking is on the old vGIC, the risk of
micro-optimizing is not worth
On 30/11/2018 19:52, Andrii Anisov wrote:
> Hello Andre,
>
> Please see my comments below:
>
> On 23.11.18 14:18, Andre Przywara wrote:
>> Fundamentally there is a semantic difference between edge and level
>> triggered IRQs: When the guest has handled an *edge* IRQ (EOIed so
>> the LR's state
On 29/11/2018 07:39, Omkar Bolla wrote:
Hi,
Hello,
I just wanted to run xen hypervisor on ARMv8 architecture, I tried on Hikey960
platform which has armv8, but latest xen giving cpu errors.
Could you please tell me, on which platforms latest xen is working?
If your platform supports
On Wed, Nov 21, 2018 at 03:11:58PM +, Paul Durrant wrote:
> 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
flight 130897 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130897/
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
>>> On 30.11.18 at 11:45, wrote:
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and, instead, adds explicit flushing at the
> end of the loops in the iommu_map/unmap() wrapper functions.
>
> Because VT-d currently performs two different
Hello Juergen,
On 03.12.18 15:53, Juergen Gross wrote:
On 03/12/2018 14:46, Andre Przywara wrote:
I think PERFCOUNTER is your friend.
CONFIG_LOCK_PROFILE and xen-lockprof on tools side?
Not sure it is still working, though. Its about 9 years since I wrote
and used it.
It does work. I've
On Mon, Dec 03, 2018 at 04:01:07AM -0700, Jan Beulich wrote:
> >>> On 02.12.18 at 18:47, wrote:
> > From: Dwayne Litzenberger
> >
> > Newer AMD GPUs store their initialization routines as bytecode on the
> > ROM. This fixes the following initialization error inside the VM when
> > doing PCI
>>> On 03.12.18 at 15:47, wrote:
> On Mon, Dec 03, 2018 at 04:01:07AM -0700, Jan Beulich wrote:
>> >>> On 02.12.18 at 18:47, wrote:
>> > From: Dwayne Litzenberger
>> >
>> > Newer AMD GPUs store their initialization routines as bytecode on the
>> > ROM. This fixes the following initialization
>>> On 30.11.18 at 13:49, wrote:
> On 30/11/2018 10:45, Paul Durrant wrote:
>> +enum iommu_flush_type
>> +{
>> +IOMMU_FLUSH_none, /* no flush required */
>> +IOMMU_FLUSH_added, /* no modified entries, just additional entries */
>
> IOMMU_FLUSH_invalid ? I think it is more descriptive of
On 01.12.18 02:25, Wei Yang wrote:
> On Fri, Nov 30, 2018 at 06:59:19PM +0100, David Hildenbrand wrote:
>> Memory onlining should always be handled by user space, because only user
>> space knows which use cases it wants to satisfy. E.g. memory might be
>> onlined to the MOVABLE zone even if it
On 01.12.18 02:50, Wei Yang wrote:
> On Fri, Nov 30, 2018 at 06:59:20PM +0100, David Hildenbrand wrote:
>> Let's pass a memory block type instead. Pass "MEMORY_BLOCK_NONE" for device
>> memory and for now "MEMORY_BLOCK_UNSPECIFIED" for anything else. No
>> functional change.
>
> I would suggest
flight 130892 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130892/
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 7 xen-boot fail REGR.
vs. 130827
>>> On 02.12.18 at 18:47, wrote:
> From: Dwayne Litzenberger
>
> Newer AMD GPUs store their initialization routines as bytecode on the
> ROM. This fixes the following initialization error inside the VM when
> doing PCI passthrough:
>
> radeon :00:05.0: Invalid PCI ROM header
Hi Juergen,
thanks for your comments.
Are you suggesting to call apic_is_x2apic_enabled() in __x2apic_disable()?
but I think that's exact what changed due to the fake xen_cpuid value.
Doing so will probably still see the EXTD bit on, and call wrmsrl to disable
x2apic.
log for
On Fri, Nov 30, 2018 at 02:03:29AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 18:44, wrote:
> > On Thu, Nov 08, 2018 at 09:05:45AM -0700, Jan Beulich wrote:
> >> --- a/xen/arch/x86/efi/Makefile
> >> +++ b/xen/arch/x86/efi/Makefile
> >> @@ -5,7 +5,11 @@ CFLAGS += -fshort-wchar
> >>
> >>
Hello Andre,
On 29.11.18 14:14, Andre Przywara wrote:
Nah, please don't do this.
Sorry for making you crying looking at this code.
It's terrible, I know. It's rather an idea.
Can you show that atomic bit ops are a
problem? They shouldn't be expensive unless contended, also pretty
lightweight
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
> Can you trace this to the Linux code that's actually making the call
> by injecting a trap when this happens?
Yes, we can. In some cases, we have to manually backtrace, but so far
we have been able to map resources to the actual source code.
> Serial port poking?
This would be a great one to
>>> On 01.12.18 at 02:32, wrote:
> Allocates an IPI-bound event channel on vcpu0 for specified domain.
Please can such changes to general code be done at the point where
they're needed?
> Is able to bypass the existence check on vcpu number since vcpu 0
> should always exist. Bypass is
On Mon, Dec 03, 2018 at 04:35:39PM +, Anthony PERARD wrote:
> On Wed, Nov 21, 2018 at 03:12:01PM +, Paul Durrant wrote:
> > The new xen-qdisk XenDevice implementation requires the same core dataplane
> > as the legacy xen_disk implementation it will eventually replace. This
> > patch
On Wed, Nov 21, 2018 at 03:12:02PM +, Paul Durrant wrote:
> 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()
>
Hello,
On Mon, Dec 03, 2018 at 09:06:37AM -0700, Rian Quinn wrote:
> > Can you trace this to the Linux code that's actually making the call
> > by injecting a trap when this happens?
>
> Yes, we can. In some cases, we have to manually backtrace, but so far
> we have been able to map resources to
On Mon, Dec 03, 2018 at 01:40:06AM -0700, Jan Beulich wrote:
> >>> On 30.11.18 at 17:33, wrote:
> > On Mon, Oct 01, 2018 at 10:26:05AM -0600, Jan Beulich wrote:
> >> --- a/xen/arch/x86/msi.c
> >> +++ b/xen/arch/x86/msi.c
> >> @@ -742,6 +742,16 @@ static int msi_capability_init(struct pc
> >>
>
On 12/1/18 1:33 AM, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from
>>> On 01.12.18 at 02:32, wrote:
> A convenience for working on development of the argo subsystem:
> toggling a local #define variable turns on just the debug messages
> in this subsystem.
I'm afraid I don't see the #define variable to toggle. I assume it's
ARGO_DEBUG, but there's no #define
On 12/2/18 3:31 PM, Manjunath Patil wrote:
> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>
>> On 11/30/18 4:49 PM, Manjunath Patil wrote:
>>> Thank you Boris for your comments. I removed faulty email of mine.
>>>
>>> replies inline.
>>> On 11/30/2018 12:42 PM, Boris Ostrovsky wrote:
On
On Wed, Nov 21, 2018 at 03:12:01PM +, Paul Durrant wrote:
> 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
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 December 2018 15:29
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; Kevin Tian
> ; Stefano Stabellini ; xen-
> devel
> Subject:
>>> On 03.12.18 at 17:18, wrote:
> This is a lingering TODO item from XSA-263. It adds support AMD's
> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
> setting into a per-vcpu setting.
>
> This can be found on:
> git://xenbits.xen.org/people/andrewcoop/xen.git
On 03/12/2018 16:24, Jan Beulich wrote:
On 03.12.18 at 17:18, wrote:
>> This is a lingering TODO item from XSA-263. It adds support AMD's
>> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
>> setting into a per-vcpu setting.
>>
>> This can be found on:
>>
With all other infrastructure now in place, offer X86_FEATURE_VIRT_SC_SSBD to
guests in cases where Xen thinks it has a working LEGACY_SSBD interface.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Brian Woods
---
xen/arch/x86/cpuid.c
On Wed, Nov 21, 2018 at 03:12:00PM +, Paul Durrant wrote:
> The legacy PV backend infrastructure provides functions to bind, unbind
> and send notifications to event channnels. Similar functionality will be
> required by XenDevice implementations so this patch adds the necessary
> support.
>
> == Future items
>
> The Linux device driver used to test this software is derived from the
> OpenXT v4v Linux device driver, available at:
> https://github.com/OpenXT/v4v
> The Argo implementation is not yet ready to publish (focus has been on
> the hypervisor code to this point). A Linux
flight 130895 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 129817
Regressions which
Hello Andre,
On 03.12.18 15:46, Andre Przywara wrote:
Well, you should be scared of the old VGIC locking scheme instead ;-)
Old VGIC locking is more mazy, indeed.
Apart from the vgic_queue_irq_unlock() function, the rest of the new
locking scheme is much clearer.
I agree,
Yes, but
1 - 100 of 152 matches
Mail list logo
