>>> On 30.11.18 at 16:12, wrote:
> I'm trying again this week to install Xen on a OVH server
> (https://www.ovh.com/fr/serveurs_dedies/infra/1801eg02.xml).
>
> It is still impossible to boot Xen with the option "dom0_mem=1G,max:1G"
> (boot : EFI->xen).
I'm sorry to say so, but nothing has chan
>>> On 30.11.18 at 13:40, wrote:
> On Fri, Nov 30, 2018 at 01:52:39AM -0700, Jan Beulich wrote:
>> >>> On 29.11.18 at 18: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
>>> 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
>>
>> *desc = entry;
>> /* Restore the original MSI enabled bits */
>>> On 30.11.18 at 22:59, wrote:
> On 11/29/18 3:58 PM, Jan Beulich wrote:
>> Altp2m-s don't matter here at all. My point is that the present,
>> unpatched p2m_change_type_range() updates the log-dirty
>> ranges with the unclipped [start,end), but calls
>> p2m->change_entry_type_range() with a pos
Hi Jan, hi Juergen,
This needs to be investigated from the kernel side
(which I'm afraid I simply don't have the time to help with).
If someone can lead me, I can give some of my time to help.
I can also provide an access to a server where the problem occurs.
Let me know what I can do.
I a
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 30 November 2018 17:07
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ; Roger Pau Monne
> ; Paul Durrant ; Boris
> Ostrovsky ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH 1/2]
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 30 November 2018 17:07
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ; Roger Pau Monne
> ; Paul Durrant ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> ; Brian
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,
Reviewed-by:
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 t
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 ar
>>> 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 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
> -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: Re:
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] amd-io
>>> 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 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 can
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 to
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
test-amd64-
>>> 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
>>
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 saveresto
>>> 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.
>>> 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 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 signature:
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 windows-install
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?
https://bl
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 di
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 EPYC
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 lin
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
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
> -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
> Subje
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 :
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).
> https:
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
> >>
> >> boot
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 bit
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 workin
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.
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 tes
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 oversubscr
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
--- a/docs
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 a/docs/par
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:
#
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 a/docs/parse-support
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.
Initial-Relea
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
cod
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 t
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 spi
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 only
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 i
>>> 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 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
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]
> >> > http://logs.test-lab.xenproject.org/osstest/l
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
test-armhf-armhf-armhf-sid-netboot-pygr
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 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,
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 u
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 it.
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 wh
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 go
On 03/12/2018 14:46, Andre Przywara wrote:
> 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 ha
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 vir
On 03/12/2018 05:04, Zhao Yan wrote:
> 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.
What causes this problem?
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 git://xenbits.xen.org/qemu-xen-traditional
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 use
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 cha
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 pas
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 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 e
>>> 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
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 03 December 2018 15:03
> To: Paul Durrant
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Andrew Cooper
> ; Julien Grall ; Suravee
> Suthikulpanit ; xen-devel de..
>>> On 03.12.18 at 16:18, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 03 December 2018 15:03
>>
>> >>> On 30.11.18 at 11:45, wrote:
>> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> > +++ b/xen/drivers/passthrough/vtd/iommu.c
>>
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 effectiv
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 01.12.18 at 02:32, wrote:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
> describes these codes thus:
> EMSGSIZE : "Message too large"
> ECONNREFUSED : "Connection refused".
If you were to go solely by what POSIX mandates to have, more
additions would
> -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: RE
On Wed, Nov 21, 2018 at 03:11:59PM +, Paul Durrant wrote:
> 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-of
>>> On 01.12.18 at 02:32, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -200,6 +200,26 @@ config LATE_HWDOM
>
> If unsure, say N.
>
> +config ARGO
> +bool "Argo: hypervisor-mediated interdomain communication"
> +default y
Until our policy changes as to wide
>>> 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 line
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 pvcalls
> 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 l
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 11/29
This appears to be a vestigial remnent of an old version of the
XSA-254/Spectre series, and has never been used.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/include/asm-x86/cpufeatures.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/includ
The semantics of MSR_VIRT_SPEC_CTRL are that unknown bits are write-discard
and read as zero. Only VIRT_SPEC_CTRL.SSBD is defined at the moment.
To facilitate making this per-guest, the legacy SSBD state needs context
switching between vcpus. amd_ctxt_switch_legacy_ssbd() is updated to take the
bti= was introduced with the original Spectre fixes (Jan 2018), but by the
time Speculative Store Bypass came along (May 2018), it was superceeded by the
more generic spec-ctrl=.
Since then, we've had LazyFPU (June 2018) and L1TF (August 2018), which means
noone will be using the option. Remove i
The need for per-core resources is a property of Fam17h hardware. The
mechanim for calculating / allocating space is all a bit horrible, but is the
best which can be done at this point. See the code comments for details.
Signed-off-by: Andrew Cooper
Parts based on an earlier patch by Brian
Sign
Introduce a new synthetic LEGACY_SSBD feature and set it if we find
VIRT_SPEC_CTRL offered by our hypervisor, or if we find a working bit in an
LS_CFG register.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Brian Woods
---
xen/arch/x86/cpu/amd.c
For gen-cpuid.py, fix a comment describing self.names, and generate the
reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
string name to a bit position.
For parse_cpuid(), introduce a slightly fuzzy strcmp() to accept changes in
punctuation, and perform a binary search ove
It is critical that MSR_AMD64_LS_CFG is never modified outside of this
function, to avoid trampling on sibling settings.
For now, pass in NULL from the boot paths and just set Xen's default. Later
patches will plumb in guest choices. This now supercedes the older code which
wrote to MSR_AMD64_LS
At the time of writing, the spec is available from:
https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
Future hardware (Zen v2) is expect to have hardware MSR_SPEC_CTRL support,
including SPEC_CTRL.SSBD, and with the expectation that
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 xen-virt-spec-ctrl-v1
The start of the series is some
>>> 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 required
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.
>
>
>>> 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 xen-virt
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:
>> git://xenb
1 - 100 of 152 matches
Mail list logo
